Jump to content

Oceanic Tracks Display


Tom Seeley
 Share

Recommended Posts

When I download the current NAT tracks from within VRC and display them, the western-most portion goes off into space rather than connecting with the entry/exit point. I've verified that the fixes have the correct coordinates in the sector file, and in fact the five-letter fixes are displayed correctly. The track hits the final LAT/LON fix, and then all tracks wander off to the same point in the southern hemisphere. (See image)

It seems to me there is something wrong with the download, but I can't see it, so don't know.

Any idea how to correct this?

 

nats1.jpg

Western tracks

 

nats3.jpg

Eastern tracks

Link to comment
Share on other sites

I believe all VRC users experience this problem. But I do not believe Ross has any intentions of further developing/updating VRC, so not sure if this can be fixed. Depending on your ATC facility/position, this may or may not be a big deal. For most ARTCC's there is no use for this feature but I can understand how this could be frustrating for an Oceanic controller.

Link to comment
Share on other sites

I wasn't expecting or asking Ross to modify the client, just wondering if there was something that could be tweaked by the user to accommodate the download. I know it worked correctly at one time by the discussions in the VRC forums on Ross' site.

Link to comment
Share on other sites

  • Board of Governors

The fixes that are showing up at 00/00 have been added to the NATs since the release of VRC. They were added effective 29 May 2014 (see data, below). I'm 99.9999% sure the oceanic track fixes and corresponding coordinates/locations were hard coded into VRC, so without a known location for those fix names, they display at 00/00. [Mod - Happy Thoughts]uming my 99.9999% theory is correct, you are correct that the only person that can fix this (no pun intended ) is Ross.

 

AVPUT 65° 02’ N 060° W
CLAVY 64° 14’ N 059° W
EMBOK 63° 28’ N 058° W 
KETLA 62° 28’ N 058° W 
MAXAR 61° 28’ N 058° W 
PIDSO 60° 28’ N 058° W 
SAVRY 59° 28’ N 058° W 
URSAP 58° 35’ N 057° 30’ W 
ALTOD 57° 42’ N 057° W 
CUDDY 56° 42’ N 057° W 
DORYY 56° 02’ N 057° W 
HOIST 55° 02’ N 057° W
JANJO 54° 02’ N 057° W
LOMSI 53° 06’ N 056° 47’ W
NEEKO 52° 24’ N 055° 50’ W
RIKAL 51° 48’ N 054° 32’ W
TUDEP 51° 10’ N 053° 14’ W
ALLRY 50° 30’ N 052° W
ELSIR 49° 30’ N 052° W
JOOPY 48° 30’ N 052° W
NICSO 47° 30’ N 052° W
PORTI 46° 30’ N 052° W
SUPRY 45° 30’ N 052° W

Don Desfosse
Vice President, Membership

Link to comment
Share on other sites

Looks to me like the issue is server-side (source):

 

Note the lat/lon of the JOOPY waypoint. Many other tracks appear to end with waypoints having lats & lons pointing to (0,0).

 

EDIT: Just noticed JOOPY was in Don's list above. Perhaps it's just a server-side update that's needed to report the correct coordinates for the new waypoints.

Edited by Guest
Link to comment
Share on other sites

VRC pulls the track data from the VRC web server, which in turn pulls it from a script running on simroutes.com, which in turn pulls it from a third party source. So either there is a problem at the original source, or at simroutes.com. I'll contact the simroutes author and see what's up.

Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy

Senior Controller, Boston Virtual ARTCC

Link to comment
Share on other sites

Well I'm 99.99999% sure that SimRoutes doesn't actually look up the fix coordinates, in this case they just come from the source.

 

I did a few tests this evening based on the data alone and couldn't manage to get the coordinates to populate for these new waypoints. The original data source has them listed as 0/0. We will try and speak to the source (who I haven't spoken to since 2007 but was an awesome guy back then). If we can't figure that out then I might have to pull the source code off of a microfiche to modify it

 

Was actually thinking about sunsetting simroutes so that I could stop funding the service that has been hosting it for the past 14 years. I guess some people still use it.... While people like Bradley might think it sucks, I think it isn't that bad for a Netscape LiveWire application and an access 98 database hacked together by a product guy who has no programming skills

 

Tom, Bill, Don, Ross and others - glad to see you are all still alive and kicking. Hope all is well.

Ian Elchitz

Just a guy without any fancy titles

Link to comment
Share on other sites

  • 10 months later...
  • 10 months later...

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...