Since X-Plane 8.50, airports have had a border polygon that defines the boundary of the airport surface area. The airport boundary polygon is probably the least understood aspect of airports, particularly because it takes effect when we cut DSFs, not when you load X-Plane.

The airport boundary does a few things:

  • If sloped runways are not enabled, it defines (roughly) the area that X-Plane will flatten to the airport elevation. If you have ever entered a silly field elevation in WED and then turned off sloped runways, you’ll see that the flattening process is not exact.
  • When we create base mesh DSFs, the area of the boundary polygon gets a grass surface texture.
  • When we create base mesh DSFs, the area of the boundary polygon has no autogen buildings.  (These two points are actually one in the same – the zoning of ‘airport’ in the DSF creation tool adds grass and removes autogen at the same time.)
  • When we create base mesh DSFs, the elevation under the boundary polygon has large bumps and spikes removed.

No More Bezier Curves

If you’ve used WED 1.2, you may have noticed that it refuses to validate airports with bezier curve boundaries.  This is because we are trying to stop the use of bezier curves for airport boundaries.

The problem with  bezier curves is that they can very easily be self-intersecting, but WED has no good test for this.  The result is (apparently) valid WED airport layouts that later crash the DSF generator.  Every time we cut DSFs, we find a handful of boundary polygons that need to be hand-fixed due to bad bezier outlines.  There were 3 in this last batch.

Furthermore, the DSF generator cannot actually use bezier curves – it has to convert them to polygons.  So the author will not get a surface area like the one they expected – there is a conversion that must take place.

Faced with a bezier curve technology that produces crashes and isn’t actually used, I decided to switch to straight polygonal airport boundaries.  So: when you work on new airports, please remove bezier curves from your boundary polygons.

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.

16 comments on “Airport Authoring: Airport Boundaries”

  1. Are two[or more] apt-boundaries allowed for one airport ?
    A highway goes through our airport (parallel between the north- and south-rwy).
    The idea is to leave this highway untouched while cutting the dsf.

  2. This has cleared up several mysteries for me. Thanks.

    I now understand that there is no point putting a airport boundary into a custom scenery package. Correct?

    Also, when I release a custom airport and the corresponding global airport is missing or wrong, then I should submit a global airport for each custom airport that I release to ensure that the DSF is cut correctly, otherwise I can get bumps and spikes in the field. Is that right?

    I’ve probably missed the opportunity to submit corrected global airport boundaries for the next DSF recut. If I submit a new global airport now, how long will it take for the corresponding fixed DSF to be released?

    Many thanks.

    1. The airport boundary is also used for flattening, so it is not useless.

      And yes – if the global default airport is radically wrong, you should try to share a correction with the global database, to get the DSF cleaned.

      I don’t know the latency on DSFs – it’s going to be an on-going process – recut a few here, a few there, not one big fat deadline.

  3. Hi Ben
    Thanks for a great program.

    One question though. What is the current thinking on the placement of exclusion zones around airports. I had been just putting them as needed to remove an odd road or whatever etc;. Is that all that is needed?

    Thanks pete

    1. I would say:
      – Custom airports need to exclude _everything_ below them – otherwise a global airport might pop up.
      – Global airports, because they are ‘last’ in line, probably don’t need to be this careful about exclusion, although it doesn’t hurt.

      1. Doesn’t this depend on how one sorts the scenery? Is “Global Airports” always ‘last in line’, regardless on where it is in the .ini?

        1. Global airports is supposed to be at the end, and for users who start with a default installation, it usually will be.

          But we are looking at a change in 10.30 that would _force_ Global Airports to be low priority, which is virtually always the desired behavior. Right now you can get it somewhere else in your .ini file, which is not so good.

  4. I’m working on a lego brick representation of Stockholm Arlanda which hopefully will go into the global airport database.

    I couple of years ago I submitted the same airport, with a boundary all around it, not knowing what I think I know now after your post. I also enclosed the whole airport with an exclusion zone. The net result of all this is that the land side of ESSA is just grass with no roads or other features whatsoever.

    So now, when I’m adding valid objects for the global airport database to my previous data, I want to correct my mistakes. It seems to me that the boundary should only enclose the airside of the airport, where I have added aprons and taxiways, and that I maybe should get rid of the cover-it-all exclusion zone altogether? Possibly adding smaller zones where it makes sense to supress things?

    Again, the intention is to create an airport for the global database.

    1. You can definitely go lighter on the exclusion zones – the v10 road networks often include the roads to airports in pretty good detail.

      In terms of the boundary I’d say: if the land class is some kind of airport surface, it should be in. If it’s city or residential or something, it should be out.

      1. Would you mind to elaborate on your comment about the boundary? I’m not sure I follow you. How can I determine the land class?

        1. What I mean is: you pull up the ortho-imagery of the airport on a mapping source and observe what parts of the airport are grass, concrete, etc. (e.g. in the airport) and what parts are not (e.g. houses, trees, lakes) and then draw an approximate boundary to capture the shape of the airport.

          (I say approximate because I think that tracing Google imagery is probably a EULA violation. But if you can see a map or image of the airport, you can sometimes construct pretty good boundaries from the nearby landmarks and the airport itself. Someday perhaps we can import OSM data into WED so that we can have good references, e.g. “here is I-80 and I know the airport is bounded by I-80 on one side.”)

Comments are closed.