Airspace Depiction

[Kevin Firth 114]

After immersing myself in this for a little while I've become increasingly annoyed by the fact that my default navdata is plain wrong and doesn't match up in any appreciable way to real life now.  PlanG is brilliant, but only displays what is in the stock BGL's

 

So, I've been turning an idea over in my head about whether it would be possible to update this stuff to make it a little more real worldy...

 

After reading lots and lots, the general prevailing opinion of the great and the good is that it's not worth doing because it can break a lot of things like AI.  The problem lies in the way [navaids] and [airways] are defined.  An [airway] is comprised of ISEC [waypoints], each of which have any number of [routes] attached to them.  Commonly the end of an [airway] is attached to a [waypoint] linked to a [navaid].  Cumulatively, all this data allows you to create flightplans with the internal planner, and provides seamless routes for AI aircraft.

 

If you break an [airway] by amending/deleteing a [navaid], [waypoint] or [route] referenced within another [waypoint] then you introduce an error, which causes things like a CTD or AI to simply disappear.

 

This complexity is compounded by MS's choice of database in which to store all this stuff.  All the waypoint and route information for the UK is held within the SIMULATOR/SCENERY/0501 and 0502 folders in files ATX05010.bgl and ATX05020.bgl. The problem is the sheer amount of data 17,000 odd lines in each...

I decompiled one of them and managed to use Notepad and Word to reformat the decompiled xml so that each Waypoint and Route was together in one line rather than indented and spread over multiple lines (I find it much easier to read xml this way). Then I simply copied the text into excel - each reformatted line now occupies one cell. All I need to do is filter the excel sheet looking for any cell containing the text of either an [airway], [navaid], [waypoint] or [route] and I get a nicely presented short list of each reference to that element.

That _should_ make it possible to change some of the information without missing any associated changes that need to be made to not break anything.. After that it should be a simple matter of copying the amended data back to the xml file and recompiling to arrive at some useable and more up to date navdata.

Theory over, I need to now find some time to take an out of date ISEC waypoint and remove/update it as a test....

[allardjd 1,853]

Kevin,

Great start to a project but I think you've been misinformed about how AI work. All of what is below is my understanding of how AI work and how they (don't) interact with formally defined waypoints in FSX.

They don't fly airways, per se, and don't really use waypoints enroute. When they enter the zone (can't remember the technical term FS uses) adjacent to the one you, the user, are in, FS begins to actually "see" them in the sense we think of and actually generate a precise position for them. The zones are roughly 100 NM squares and FS looks at a block of nine of them - the one you are in and the eight adjacent ones.

Before an AI aircraft enters the zone adjacent to you it is just a table entry and FS is only looking at if, when and where it will enter one of the zones adjacent to you. That is, of course a rather dynamic thing as your position changes, but it has nothing to do with waypoints.

All the AI arriving at an airport will go to a pre-defined position somewhere not far from the airport and begin their "approach" such as it is, from there. That point is different for different active runways, so depending on number of runways there may be several for any given airport, but the active runway in use determines which of them is being used. That "initial point" (my term - not sure what the formal name is) may or may not be a Waypoint as formally defined in FS but even if it coincides with an actual Waypoint, I don't believe deleting that Waypoint will affect the traffic.

If you've ever de-compiled an FS traffic program you know there are three separate files, Aircraft, Airports and Schedule. The schedule file only contains airport IDs, departure times, AC type, altitude, flight plan type, Flight # and associated information. There is NO route information anywhere in the traffic file aside from the beginning and ending airport code for each leg.

Anyway, without in any way detracting from a great and worthwhile project to improve the navaid data in FSX, I believe your concern for disrupting AI traffic by editing FS waypoints is misplaced. I believe you can safely add, edit and delete FSX Waypoints without causing any disruption of your AI traffic.

Keep up the good work - I'm watching this with interest.

[Kevin Firth 114]

Thanks John, I've never really played with any AI files, so if my understanding was wrong then so be it I did think it entirely logical that AI flightplans would follow the same structure as a user but clearly not!

My understanding there came from a post by Jon Masterson (ADE) at FSDeveloper discussing the reason why an ADE created glideslope had disappeared when some stock navdata had been changed. Perhaps he was refering to how amending data had affected the pre-determined start of AI approach and how that was interacting with ADE created elements and approaches...

It will still be necessary to get all the links right in order for that data to be displayed properly in PlanG or elsewhere, and for pilots to be able to use the built in flightplanner without CTDs..

Thanks for the heads up its always good to learn something new! Cheers K

[allardjd 1,853]

My understanding there came from a post by Jon Masterson (ADE) at FSDeveloper discussing the reason why an ADE created glideslope had disappeared when some stock navdata had been changed.

 

 

I would not dispute Jon if he said that the sun would rise in the west tomorrow.  I'd get up early and sit facing west waiting for it to happen.  He IS the man on all of this kind of thing.  I suspect, however, that he was addressing airport attributes, not so much AI behavior.  You are correct, however, that near airports, AI can be influenced by things near and associated with the airport.

 

It will still be necessary to get all the links right in order for that data to be displayed properly in PlanG or elsewhere, and for pilots to be able to use the built in flightplanner without CTDs..

 

 

You're absolutely right in that.  For Plan-G and for our use of waypoints and routes, you've got to be careful with sequencing and all that.  Enroute Waypoints are very easy to add in FSX but tying them together into routes or integrating them into existing routes is a whole different kettle of fish.

 

Terminal Waypoints are yet again complicated because they are not stand-alone entities in the FSX bgls.  They are associated with a specific airport and are thus buried in the FSX airport bgls.  To make it even worse, FSX combines many airports into a single bgl, so it's a real snakepit.

 

Hats off to you for even considering jumping into the deep end on this.

 

John

[Kevin Firth 114]

Thanks John, I do appreciate this will be like walking blind into a minefield snakepit.   I'm sure (as you've proven) that there's a lot I don't know yet!!

1. If I can start to get to grips with some waypoints and routes that will be a win.
2. Next up I'll tie that into updating some of the VOR and NDB navaids that have changed or been removed.
3. After that I'll look at terminal waypoints and how they fit in

By necessity though number 3 may have to be fudged as it is nigh on impossible that one set of updated bgl's could ever cover the endless permutations of addon airports that people may be using... we'll see

Cheers K

[stu7708 244]

Kevin,

Great start to a project but I think you've been misinformed about how AI work. All of what is below is my understanding of how AI work and how they (don't) interact with formally defined waypoints in FSX.

They don't fly airways, per se, and don't really use waypoints enroute. When they enter the zone (can't remember the technical term FS uses) adjacent to the one you, the user, are in, FS begins to actually "see" them in the sense we think of and actually generate a precise position for them. The zones are roughly 100 NM squares and FS looks at a block of nine of them - the one you are in and the eight adjacent ones.

Before an AI aircraft enters the zone adjacent to you it is just a table entry and FS is only looking at if, when and where it will enter one of the zones adjacent to you. That is, of course a rather dynamic thing as your position changes, but it has nothing to do with waypoints.

All the AI arriving at an airport will go to a pre-defined position somewhere not far from the airport and begin their "approach" such as it is, from there. That point is different for different active runways, so depending on number of runways there may be several for any given airport, but the active runway in use determines which of them is being used. That "initial point" (my term - not sure what the formal name is) may or may not be a Waypoint as formally defined in FS but even if it coincides with an actual Waypoint, I don't believe deleting that Waypoint will affect the traffic.

If you've ever de-compiled an FS traffic program you know there are three separate files, Aircraft, Airports and Schedule. The schedule file only contains airport IDs, departure times, AC type, altitude, flight plan type, Flight # and associated information. There is NO route information anywhere in the traffic file aside from the beginning and ending airport code for each leg.

Anyway, without in any way detracting from a great and worthwhile project to improve the navaid data in FSX, I believe your concern for disrupting AI traffic by editing FS waypoints is misplaced. I believe you can safely add, edit and delete FSX Waypoints without causing any disruption of your AI traffic.

Keep up the good work - I'm watching this with interest.

 

Just an addendum to this from what I've understood.

 

All of the above is true for .BGL-based AI, but I've read somewhere that Ultimate Traffic works in a different way. Somehow it injects all it's traffic from the application, and the UT based traffic do follow airways.

What I don't know if this is done using navigation data from FSX, or if it routes the traffic based on data included in UT. The same method for injecting traffic is also used by VoxATC if I remember correctly.

[Kevin Firth 114]

Thanks Mikael, that's really useful and I'll do some more research based on that. Cheers K

[stu7708 244]

I can also add that I know that Traffic X and Traffic 360 from Just Flight uses .BGL based AI.

 

Not sure if My Traffic 2013 from Aerosoft uses the .BGL method or some other system.