jm6087 wrote:...As with any place mapped, no place should be mapped just because GIS-L or even a website shows something there. If there is no airport/airstrip then it shouldn't be mapped.
Just because McDonald's has a place listed on their own website with an address and phone number, etc, doesn't mean you map it if the McDonald's does not exist in real life.

This is ostensibly the crux of what I am believing whether or not I conveyed it correctly. If there is nothing there, in this case, a legitimately defined airstrip and/or associated support facility then no area place should be applied. As for the Borrengo example my only effort there was to offer what I could see from the pavement markings to address the topic of housing / airport boundaries and also what I thought could be contributing to the display issue and have always stood by the premise there will be exceptions to the rule and also local leadership can and should be involved with those scenarios. As with any of the guidance, there is an opportunity to improve understanding as we encounter more anomalies to better define our practice.

Airports are somewhat near and dear to me and not only have provided a living for me but also are a subject I cut my teeth upon when I started volunteering with Waze. It's a topic I can get involved with since I don't know enough coding to keep up with the script folks

Kartografer wrote:
So instead of coming up with complicated and subjective rules, let's just use the distinction already made by the FAA.

FAA paragraph 1-2-7e wrote:Two−letter, two−number identifiers are assigned to private−use landing facilities in the United States and its jurisdictions which do not meet the requirements for three−character assignments

If an airport has a four-character identifier, don't map it. All the examples given of places that shouldn't or should be mapped, on both sides of the argument, fit this distinction.

Purely for the purpose of thinking out loud and clarification the four character/private use fields would A) Not be mapped at all, or B) Mapped as an airport but not as an area place allowing it to be searched, or C) mapped as a Place Point but under a different place category? In the case of B or C could we utilize the naming convention MacroNav mentioned or something of the like?

Purely thought for discussion. I think this is a much needed conversation and thank all who have put in their thoughts on the subject.

$0.02

I would get behind this description.

jm6087 wrote:

==Scope==
Airport area places should be drawn for all public-use airports, regardless of size or facilities. Private-use airports should only be mapped as Area Place if a large clearing and/or easily-recognizable aviation-related structures are visually obvious from public roads or satellite view, or the airport offers services to the general public such as flying lessons or demonstrations. For how to distinguish between public-use and private-use airports, see Names.

===Category===
The airport category should only be used either for facilities that qualify for airport area places or on point places for airline terminals. For other airport-associated business places, such as charter services or air freight forwarders, a different category should be used.

Cleaning up the strike-through sentences this reads very well. I believe this is clear and concise as far as the base fundamental breaking point between whether to map an airport or not. Individual examples that are on the fence can be handled within local leadership.

One of the original issues that came up as an example is some very rural, unlit, unmanned clearings in Alaska that while having an FAA identifier they lack support facilities or even utilities for that matter. In essence, they are someone's clearing on their property. I believe, if I recall correctly were do they actually meet the criteria of an airport category while only having a grass strip on private property. Somebody else add to this if needed.

And we can always clarify the search results with a specific description for those private fields in the naming convention akin to what was mentioned earlier - "Private Airfield - Anderson Lake 0AK1" or
"Private - Anderson Lake Airstrip 0AK1".

The airfield name remains searchable if needed.

Thanks, it is good to have something on this.

It would be good for this page to resolve a conflict I've noticed over the years. Some folks like for the airport Area Place to "look" like an airport. The most extreme example of this is when an editor lovingly traces the tarmac outline, including runways, taxiways, and terminal areas. Some of this detail is lost in app rendering, but not all. Two downsides are (a) this doesn't match our conventions for other Area Places and (b) a "form fitting" Area Place may end up smaller, and if it ends up smaller it will render with less significance on the app.

Other folks think the AP should reflect airport property, sometimes as expressed as "mapping to the fence line". One possible downside is the inclusion of airport tenant businesses that commonly --but not always -- involve aviation. Mapping to the "fence line" includes these areas because they are technically on airport property. A related downside is that large amounts of open and/or unimproved space that are technically under airport authority will be mapped as part of the airport.

Either approach can involve a terrific amount of work. Twice I have had all my work on an airport boundary deleted (using the "fence line" principle) -- one of which had been locked at 6! -- so I have lost interest in mapping airports. But it would be nice to settle the question of fence-line versus "airport-like" subset.

Personally, I favor the "fence line" principle because it is simple and I think the upsides outweigh the downsides. I'm willing to be persuaded otherwise, but it could be a lot harder to craft guidance for "airport-like" Area Places.

Kartografer wrote:I'm not sure how including airport tenant businesses in the airport area is a downside.

I'm with you, but somebody sure thought it was a downside at one of the major airports I set up. Wiped out all the detail boundary that I'd mapped from official sources and replaced it with a rough seat-of-the-pants outline that more or less looked like the runways.

How about something like this?

Each airport should be drawn as a single area place, covering all airport-managed property and including any open space, parking lots, runways, taxiways, terminal buildings, control towers, orairport tenants, and other structures. This will ensure visibility on the map.

[EDIT: Added parking lots for good measure.]

OK, I've made the changes to the area-extent paragraph in the Kartographer draft article. Thanks to Kartographer for the great work and to everybody for their comments.

tcalvert317 wrote:Is it possible that airport wipe-out might have been from a galaxy far, far away, and might not be a factor anymore?

I don't know. The name associated with the airport after the horrible loss of data was that of an R6 Global Champ who is still active but, in my experience anyway, uncommunicative.

I hasten to add that, of course, it may not have been the GC who erased the outline work; the GC may in fact have tried to rescue the airport in haste after some R4+ editor really messed it up (at least I think it had been locked at 4).

Regardless, I have encountered work by other editors that suggests they like "airport-looking" Area Places instead of mapping property boundaries, so I do believe this is a useful clarification.

(The other two airport wipe-outs in my experience -- both San Francisco and San Jose International Airports -- appeared to have resulted from visiting R6 editors "rubber-stamping" Place Update Requests and unintentionally approving "trojan horse" deletion requests. No wiki article in the world will keep that from happening.)

tcalvert317 wrote:How can we ensure that this is adequately vetted and discussed so that changes aren't made then undone?

We can't. The best we can do is follow the process like we're doing, then hope. Ultimately, we have no central authority that can compel anything.

On the bright side, it has been quite rare in my experience that a highly-decorated editor will come in out of the blue, "keyboard blazing", and unilaterally undo agreed-upon wiki changes with zero discussion or notification. Oh it has happened, for sure. But it's rare.

Much more likely is that leading regional editors will, when they find out about a wiki provision with which they disagree, simply institute a regional departure from the wiki. This is a completely natural human response; the conflict between regional and central authority goes back 5000 years or more.

Finding the right balance between regional and central authority within the national and global Waze volunteer ecosystem is a fascinating question (no sarcasm intended, it's an interesting topic). But probably this thread isn't the best place to discuss it