I agree with Pesach's points. I agree with the address requirement only as far as it is practicable – not everything has an address, though.

PhantomSoul wrote:Airports have short codes that are also practical to show as prefixes, since they are often well-known, and from a distance, airport destinations are often searched for by airport name or some common reference to the airport as a whole (like its code), so that would work well.

I thought airport guidelines were codified in the wiki, but I guess not.

This is my recommendation:

• An Area Place for the airport, with the navigation point placed as follows:
  • If there is only one terminal, place the navigation point at the entrance to the terminal;
  • if there are multiple terminals, but only one public entrance to the airport facility, place the navigation point after that entrance but before the ramp to either terminal;
  • if there are multiple terminals and entrances from both directions, place it somewhere reasonable.
• Name the airport using the airport's name followed by its 3-letter IATA code, set off in
  parentheses, e.g., "Louis Armstrong New Orleans International Airport (MSY)".
  • Set, as an alternate name, the three-letter IATA code alone, e.g., "MSY".
  • If a three-letter IATA code is not available, use, in this order of preference: (1) the FAA code, if in the US, or (2) the four-letter ICAO code, everywhere the IATA code is called for.
• Place a Point Place at each of the following locations, if it is distinct and possible to navigate to:
  • each terminal, by name, if there are multiple terminals;
  • "Departures", if there is a distinct ramp for departures;
  • "Arrivals", if there is a distinct ramp for arrivals;
  • "Parking";
  • "Rental Car Return".
• Name these Point Places as follows: "IATA Code - Place Descriptor", e.g., "MSY - Arrivals".
  • If an airport has multiple terminals, there will likely be multiple Departures and Arrivals ramps, so place the terminal name between the IATA code and descriptor, e.g., "DTW - North Terminal - Arrivals".
  • If international and domestic departures are on separate ramps, place a point place for each, e.g., "DTW - McNamara Terminal - International Departures" and "DTW - McNamara Terminal - Domestic Departures".
• Place these Point Places at a place relatively near to the start of the ramp.

The one thing we can't yet do is add alt names to Places in the production editor, but I'm confident it's coming real soon.

DwarfLord wrote:I definitely agree that the IATA code should be part of the name. As far as where to put it, my own preference is to place the IATA code first, with no dashes or parenthesis. For example, "SFO San Francisco International Airport". Point places would be named similarly, "SFO Domestic Arrivals" etc. This convention would offer a nice and clean-looking list of all SFO-related destinations in any alphabetically-ordered presentation returned from a search for "SFO".

I might agree with the removal of the hyphen from the points, but I don't like that way of naming the area. Area names show up on the map, so how they look is important. Also, I prefer to see the general airport area listed separately from all the particular destination points.

Should we not follow the convention already agreed upon for naming runways? That convention uses IATA first, ICAO second, and only then the domestic authority's code (the FAA code in the US).

Yes we should!

DwarfLord wrote:

sketch wrote:If a three-letter IATA code is not available, use, in this order of preference: (1) the FAA code, if in the US, or (2) the four-letter ICAO code, everywhere the IATA code is called for.

Should we not follow the convention already agreed upon for naming runways? That convention uses IATA first, ICAO second, and only then the domestic authority's code (the FAA code in the US).

Now that I'm working on airports, personally, I think in the US the FAA code might be preferable to the ICAO mark – the FAA code typically matches the IATA anyway, but where it doesn't, it remains a 3-digit code. Also: ICAO's "K" is basically redundant – we know our search results are gonna be in the USA. You're not gonna search "ACP" in the States and expect a route to Iran.

At least, I think this is worth some discussion.

DwarfLord wrote:My understanding of the runway naming protocol is that we go to ICAO only if there is no IATA code at all. It may be that if we went to another 3-letter code in such (very very rare) cases that could be confusing...?


Sent from my iPhone using Tapatalk

It seems that...

• Each airport in the US have an FAA code.
• If an airport in the US also has an ICAO code, the ICAO code is "K" followed by the FAA code.
• If an airport in the US also has an IATA code, the IATA code is the same as the FAA code.

This list is in decreasing order of inclusiveness. In other words, every airport I have seen has an FAA code. Some of these airports also have ICAO codes. Some of the airports with ICAO codes also have IATA codes. In other words, I've yet to see an airport with an IATA code but not an ICAO code, and I've yet to see an airport without an FAA code.

When an airport has only an FAA code, it's often alphanumeric, like L40 or F88 or 9M6.

When an airport has an FAA code, an ICAO code, and an IATA code, the IATA and FAA codes are the same, only letters, and the ICAO code is "K" (for the contiguous US) followed by the IATA/FAA code. For example, MSY/MSY/KMSY or JFK/JFK/KJFK or DTW/DTW/KDTW or PTN/PTN/KPTN.

The contentious point here is the airports that have ICAO and FAA codes, but not IATA codes. The ICAO code is just the FAA code with a "K" at the front (for the contiguous US). For example, HDC/KHDC or ACP/KACP or IYA/KIYA. This is sometimes done when the FAA code is used elsewhere in the world – see ACP/KACP above – the IATA ACP is in Maragheh, Iran.

But destination searching on Waze is not international like that. No one will be looking for the ACP in Louisiana and accidentally find the airport in Iran.

IATA codes are the ones used by the public when referring to airports, so of course, they should be used when they are available. They are identical to FAA codes, so as such, FAA codes are also the ones used by the public when referring to airports. Putting ICAO next in the preference order leads to an incongruence visually and with the public perception of airport codes, and use of ICAO codes is unnecessary on a non-international level.

Note that this discussion applies only to the contiguous US. Alaska and Hawaii are within different ICAO code ranges. We'd have to figure out whether ICAO or FAA codes are more prevalently used, because ICAO and FAA codes don't always match in the same way in Alaska and Hawaii.

(Also, related but not really related, I still don't care for the airport codes on the runway segments themselves. It's redundant and duplicative. But that's not here nor there.)

Well, good thing I'm talking about Place names

Let me know when you post that thread. I have a lot to say

There is in the client, there is a option to flag certain issues.

Gotta read all the notes on the release to see it. Look under known issues.


I am not sure if anything like that will transfer to the editor (which is what I assume you are referring too) but the client will have tools built in.

CBenson wrote:I guess that you we can give the go ahead to mark anything that fits the new categories, except for residence.

I'm assuming this is because houses are better handled by the House Number interface. That being said, would not a residence/home point place at the office/clubhouse of an apartment complex reasonable? Mark all the buildings with their house number in that interface, but make a point place Named for the name of the apartment complex at the door of the office where prospective tenants would want to check in.

I was not proposing to disregard the wiki, either. Nor have I. (Well maybe once as a test case, but I'll delete it if it hasn't been already). I'm just a newb throwing out ideas.

davielde wrote:If we define "Residence/Home" outside of a typical house, I'm fine with altering the wiki. If we opted to make every home on every block a Place, that's too monumental of an effort for me, and I'll choose to spend my time on other things. I think that the interpretation of "residence/home" as a typical single-family house may have been what made the Champs recommend not mapping when they initially voted earlier in the year.

That would be silly. Mapping out single-family homes is better served by the "House Numbers" interface. Ditto for the individual buildings of an apartment complex, IMHO.

davielde wrote:Residences that serve as potential destinations for more than one user such as co-ops, college dorms, nursing homes, or the like certainly have value being added as Places. For apartment complexes, I would personally lean toward not mapping the office as a "residence/home" since no one lives at the office, and instead use the "offices" category. I haven't mapped one in reality though.

With regards to apartment complex offices, I was thinking in terms of the pending inclusion of category searches in the app. If I were new to an area and looking to rent an apartment I would not think to hit the "Office" category, but I might think to hit the "Residence/Home" category. Along those lines, though, now that I think about it, it might work and be OK IAW current guidance to make the office a point place with primary category of "Office" and secondary category of "Residence/Home"?

DwarfLord wrote:I'd support altering the wiki to allow use of "Residence/Home" Point Places for the front entrance of multi-family destinations.

When it comes to Area Places (which I think is the implication here) it brings us back to what principles we want to follow for Area-vs-Point. It's critical to note that we are not talking about the ability to create destinations; both Area and Point provide navigable destinations. We are just talking about rendering on the display to every Wazer in the area.

It's unanimously agreed (I think???) that it's inappropriate to use the "Farm" Area Place to mark all the separate farms in an agricultural region. The display would be an ocean of "Farm" polygons and nothing would stand out. The driver would be driving against a gray background instead of a white background.

Well, in certain areas there are wall-to-wall residence complexes. If every one is marked with a Residence/Home Area Place, a driver's display will turn more-or-less solid gray. Even if the area places are created with building outlines instead of being mapped to the fenceline, that's a lot of stuff on the display and none of it will stand out. Maybe the community will decide that is OK in principle, but it hasn't decided yet.

So maybe the initial approach can be provisionally to change the wiki to support Residence/Home as a Point Place for named multi-family structures or complexes?

Before we go further and OK use as an Area Place, we really have to get our Area-vs-Point principles nailed down. "Stands out visually from its surroundings"? "Of local interest even if visually inconspicuous"? Or "Editors' choice"?

Couldn't agree more. I was only proposing use of a POINT place for an apartment complex. NOT an area place in any aspect of residence. No "place" at all for single family homes as that is better handled by the "House Numbers" interface. Mapping out homes (and/or) farms with area places would make the map a wall of grey and kill the whole point of places/landmarks.