EXPERIMENTAL USE ONLY!!! -- [What?] -- Login to add public annotations [How? >>YouTube].

Last week I spent a little bit of time looking at a bug: some ILS approach paths have tall buildings in the way.  For an example, fly the ILS 22L into KBOS, and look to your right on short final.  I hope the people living in those apartment buildings like watching airplanes!

A Library Bug

It looks like the bug is caused by a bad mapping of art assets in the library.  The global scenery DSFs contain virtual paths for art assets, which are then mapped to real autogen art assets by the library.  The virtual paths indicate the legal height ranges that the autogen can extend to, e.g. the library path

lib/g10/autogen/urban_high_solid_f_30x40_v0.agb

Indicates that this art asset fills a square block at least 30m deep with roads on all four sides, and the buildings should be between 32 and 40m tall for the tallest ones included. (The actual encoding of the library is partly handled by scripts we use to build the global scenery, and the encoding is byzantine enough that neither Alex nor I understand the entire thing.)

Well, if the virtual library path calls for a low building but the physical art asset contains tall buildings, you get skyscrapers in places you did not want them.  And that is exactly the bug causing the ILS incursions.

I have an edit to the library paths for our next release (probably 10.30) that should fix this problem.  The good news about this being a bug in the library (and not the DSFs) is that a single library fix will fix the problem everywhere.

For the Brave

(This is a hack to the sim…don’t try this if you aren’t willing to break your copy of X-Plane.  If you try this and your sim dies, please don’t contact me or tech support!)

If you want to patch this bug yourself now in 10.25, simply locate the file

Resources/default scenery/1000 autogen/library.txt

and replace it with this file: library.txt. Warning: because this is a mod to the sim itself, when you go to update, you will get a warning as to whether you want to overwrite the file.  When the next beta or release comes out, do overwrite this file!

What About the Raw Data

I also wrote some code to attempt to ‘protect’ the ILS approach path in our DSF generator.  Here’s a picture:

ksan_approachWhat you see here is a color-coded trace of height limits for autogen.  Red are the strongest height restrictions, yellow less so.  The height restrictions take into account not only the glide slope, but also the terrain; in the case of KSAN, the airport is at the bottom of a hill next to a mesa, so the ‘red’ (low flying planes) zone is quite large – even when a plane is on a 2 mile final, the plane is low to the ground because the ground is higher up.

The logic of the code is to let all ‘known’ tall buildings exist, but limit any generated tall buildings to follow the height restriction.

Here’s the thing: having coded it, I have not caught any cases where the autogen buildings were violating the height restrictions!

Buildings that we generate (without obstacle data) always have a maximum height that is a fraction of the FAA-spec’d tallest building.  The idea is that if the FAA says there is a single 80m (roughly 20 story) building, then the nearby buildings are probably somewhat tall, but they’re not also 80m – if they were, the FAA data would include them.  So we might generate some 40m buildings near the 80m building to create a plausible ‘neighborhood’.

From what I can tell, the fact that the generated buildings are so much lower than the FAA datapoints keeps them out of the approach path, and the actual cause of tall buildings has been the library path misalignment.  (For example, in the KBOS 22L case, the block has an 8m height restriction and yet the buildings are either 50m or 70m tall, I can’t remember which.)

I think I am going to keep the ILS-protecting DSF generation code around – it’s useful to have approach paths noted, and it’s something we’ve been intending to do for quite a while.  But the library fix is what will make a real difference.

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

21 comments on “Clearing the Approach”

    1. I actually think it’s missing from our FAA data, which is weird. But _if_ it was in the raw data it _would_ be preserved – the algorithm doesn’t nuke obstacles that are declared by external data to be ‘in the way’ (like the KSAN 27 parking garage).

  2. Heads up for others: the hack didn’t work but it was worth a try, thanks. 😉
    log.txt says:

    :21:46.315 E/SYS: | lib/g10/terrain10/fruit_tmp_sdry.ter
    0:21:46.315 E/SYS: | (io_dsf.cpp:554)

    2. Sounds like as if you did “replace” the library.txt in “1000 world terrain” instead of “1000 autogen” (as Ben explicitly stated). Be careful, there is more than only one library.txt out there …. 😉

  3. This is great news.

    On a related note, is a fix planned so that ATC won’t make me descend into mountains around the airport I’m about to land at?

    This happens from time to time.

  4. Can you get this to work for trees as well? Approach paths are often suffer incursions by trees, especially upto 1 mile away from the runway threshold in tropical rainforest regions.

    1. No – the trees are all pretty similar height, so changing the library won’t help. Most of the trees that are on the runway are due to a data error; simply recutting the airport should fix the problem. In a few cases it might be necessary to modify the boundary polgyon in the apt.dat.

  5. This was a very interesting read, thanks. It’s always nice to see some concrete examples of your constant work on X-Plane!

  6. This is good news – thank you. This bug also affects KSNA, where I regularly fly from. At this airport, its not just that the people living in the apartments can see aeroplanes passing within metres of their virtual sofas, but, to make the runway at all you almost need to induce a stall about 200m out of the airport once you’ve cleared the last building!

    Looking forward to seeing the fix make it into the non-beta release soon, too.

    Keep up the good work.

  7. Telepathy is a strange thing…I just tried to figure out by myself yesterday how to fix that and I started with library.txt but didn’t know where to look exactly…Today I checked your blog and…Voila!
    I can confirm that your fix worked like charm for me.
    Thanks!

  9. On the plus side, there are now no longer any high-rise buildings anywhere near my local airport, and summarily anywhere near my house (*as there shouldn’t be). Bravo!

    On the minus side, the local capitol city has taken a turn towards suburbia once again, with the former industrial/commercial buildings supplanted with quaint neighborhood houses and some brownstone row houses.

    I win some, I lose some… 🙂

    Win some, lose some.

    1. Yep – this fixes the wrongness of tall buildings in the flight path, but without a bigger set of art assets, we can’t get the desired effect of “height where we want it, not where we don’t.” My other comment describes the axes the AG set is supposed to cover.

  10. I love this. I’ve been working on modeling out our small town airport here and the surrounding area. My wife and I have had a bit of a chuckle at all the autogen sky scrapers in town though. As a side effect our small town has become small again. 🙂

  11. Off topic but USGS is no longer offering Geotiff products and I can’t edit the airports without it.” Is there a solution coming ? I am stuck at world editor tutorial # 4…. And I don’t understand the USGS conversion script instructions….

    “As part of this data staging effort, USGS is transitioning High Resolution Orthoimagery (HRO) tiled products from an uncompressed GeoTIFF (.tif) image product to a JPEG 2000 (.jp2)”

    1. The USGS seems to have a policy of converting their data from industry standard formats to formats that are a PITA.

      There’s already a bug filed for this, and some work already coded. I don’t know when it will ship though.

Comments are closed.