The flattening is extremely crude.

http:/2007/01/airport-flattening-the-untold-story/
http:/2007/10/how-flat-is-flat/

The flattening effect may not be able to produce the detailed contour you want.

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.

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?

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.”)

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?

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.

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.

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.