Sketch — I just looked at this location (you mean 400 Bellemeade Blvd, not 400 Bellemeade Dr, right?). There do not appear to be House Numbers for that street on the Waze map. Using the app to search for 400 Bellemeade does return Gretna, but isn’t that because it’s getting the the pin from Google, which returns Gretna? Would the Waze app search switch to Timberlane if the HN were enabled?
Sorry, it was Westmeade Dr I’d put all the HNs on so far. I knew “Bellemeade” was the name of the subdivision and also a street in Timberlane, but that’s about all I got right :lol:
Ah, OK. So, I duplicated your results! The app says Gretna in the initial search screen, in the destination info pane, and in the routing instructions (after a 2033-mile drive on I-10 E). But now I’m bewildered as to why, when Timberlane has been assigned as that location’s primary city. It means Waze must be deciding to ignore the primary city in favor of other data.
Do we know why this is happening and where those “other data” are that Waze is using? Google? If Waze ignores the primary city under some circumstances and for some purposes I’d have to reframe my thinking about this.
As I understand it, all or virtually all address searching in Waze is done by matching from Google one way or the other.
When you search “404 Westmeade Dr, Timberlane” in Google Maps, it brings you to the right spot but displays “404 Westmeade Dr, Gretna”. At this point, “404 Westmeade Dr, Gretna” is passed along to Waze, which finds its HN match, 404 Westmeade Dr, Gretna, through the alt name.
My belief, therefore, is that the resolution of “Timberlane” to “Gretna” for addressing purposes is happening Google-side, before the search for the HN is done.
At any rate, Google is handing Waze “404 Westmeade Dr, Gretna”, and Waze is showing us “404 Westmeade Dr, Gretna” from the alt name.
In most situations, the user would be searching for the address with the USPS city name anyway, which should be in the alt name in many cases. The fact that Waze returns the search result with that alt name instead of with whatever the primary city name might be is particularly encouraging to me. In this case, we can try to trick it, but Google won’t let us.
I believe that gives us latitude to use city names that would be helpful in map display and on alerts but aren’t always helpful for addressing—because they won’t be used for addressing where they aren’t wanted.
A street can have at least 12 alt names (didn’t try more), but really the city question comes down to three different purposes:
- Which city labels should be displayed on the map and where?
- Which street/city combinations should be supported in address and place search?
- Which cities should be listed in report locations?
It’s pretty clear that to support address and place searching (purpose 2), we need to have USPS cities listed somewhere. People almost always give residential addresses based on what’s written on their mail. That will be a preferred city or another recognized city, so the guidance on the city names page says to add alt names to segments based on the preferred city given by the USPS for the ZIP code that the address belongs to, if that city is not in the primary name. To determine what that is, I’m pretty sure that the USPS routes give more accurate information (actual USPS mail routes) than the red outlined areas (ZIP code tabulation areas combined for simplified statistics by the Census Bureau), so I just use the mail routes. I understand that the USPS is not the ultimate authority on addresses; that actually rests with local governments, and sometimes the USPS can be out of date on new addresses.
Businesses almost always list their address with the preferred city given by the USPS or another city recognized by the USPS. For places, just use the city that they give for their address.
So in the case of Queens, to me it seems like the current guidance on the city names page is sufficient: Just add alt names with the preferred postal cities of each ZIP code on each street that they serve. However, like with anything related to cities, your local guidance may supersede that. CDPs and hamlets (in NYS) are both unincorporated areas, but CDPs are defined by the census bureau, and AFAIK hamlets are defined informally. For primary names it’s even simpler (though I’m not a local, and local guidance may differ): All land in NYC is incorporated into one of the five boroughs, so all primary street names in Queens should use Queens.
Back to DL’s amended proposal:
By USPS name, you don’t mean existence as a preferred or other recognized name for a ZIP code but rather simply whether putting the city and state into the ZIP code finder by city and state tool spits out a result?
I also did some test searching with address and neighborhoods, and it’s nice to see that Google’s fuzzy searching supports any form of search we throw at it, basically, as long as the street has a nearby on it, so it makes me worry less about the search aspects of whether or not to put certain city names in the primary field. You can even search by neighborhood, like Fruit Belt, NY or Franklinton, OH, and you get a Waze result in the right place.
@DL, it seems like with Timberlane and Gretna, Google search is converting Timberlane into Gretna as the preferred address, then passing that over to Waze.
Correct. The idea was that, when faced with the question of whether it’s a “neighborhood” or a “bona fide city”, a necessary (but not sufficient!) condition would be if USPS simply recognizes the name in any context, even a deprecated context. If USPS gives no results for the name at all, that would rule it out for use in the primary name field (i.e. it would be a neighborhood). If USPS did recognize the name, that would not be the end of the decision tree; one would then move on to whatever other criteria are applicable.
Indeed, that would be my first take, and if I’m not mistaken sketch’s as well. One question is whether Waze is doing things that way intentionally or whether it is a byproduct of some other decision that could be revisited in the future, with consequent changes to preferred address formation.
As I understand it, there is roughly 0 chance of Waze ever moving to a totally native search, because it’s something that Google is pretty good at and something that is really hard to develop.
USPS doesn’t recognize many villages (small incorporated local government units) in Ohio. I imagine this is true in other states as well. In my opinion, anything that’s incorporated should be mapped, but I can get behind using incorporation or USPS recognition as a minimum standard, at least for my state. Again though, the rules about cities are so different across states, I don’t know how well this idea can work in other states.
That would work great for me too. I love it when we can forge national agreement rather than splintering guidance. But as you say things are so different from state to state, and some experienced editors are saying that there are times when it’s useful to map as a city an area most folks agree is a neighborhood.
I have no idea where to draw the line. In fact I have no idea if the reasons behind the original prohibition against mapping neighborhoods (which was already in place when I started editing over 5 years ago) are even valid any more.
I started this thread specifically because Waze had mapped “UC Davis” as a city. While driving I saw it displayed prominently on the app, right next to “Davis” in equally large letters. I said to myself “that’s ridiculous, UC Davis is a university, it deserves and already has an Area Place, but the city is Davis”. I brought it up in Discord, and a local editor pointed to guidance that said the city should match the Waze city polygon. Thus my original post.
So, whatever we come up with as justification for a city, I just want to be sure “UC Davis” won’t qualify :mrgreen:
I never quite understood the reasoning for that. I’ve still got the “LSU” city name in Baton Rouge that I’ve never gotten around to doing anything about. Maybe it was to allow for the display of area places on campus (because Waze still can’t figure out places within places unless they’re different colors, I guess).
Of course, all that being said…
:mrgreen:
I do think you’ll find some conflict with the Military Bases guidance unless you allow specifically for it.
:mrgreen: UNIVERSITY LA is recognized (if deprecated) as a place name for LSU by the USPS??? Do people write to GOVERNMENT DC, BOARDWALK NJ, BEACH HI, or SCHOOL CA?
OK maybe relying on USPS recognition to rule out silly city names isn’t such a good idea.
Virginia has adopted a guideline that if the USPS name for addresses on a given segment is different from the primary city name on that segment (including “No city” as a primary name), then the USPS name should be added as an alternate name.
Given that we’re unlikely to reach any nationwide consensus on primary city names due to state-to-state differences in how local governments are organized, how about adopting the Virginia guideline instead? A segment can have multiple alternate names, corresponding to variations on the city name accepted by USPS, so that’s not a problem. If one of them isn’t commonly used and no one ever searches for it, there’s no harm done. But if a user does search for “123 Jones St, University, LA” for some reason, we’d have it on the map as an alternate name and the search would go to the correct location.
Note that the existing city name guidance only covers segments with “No city” as the primary name, so it doesn’t cover situations like Queens where the primary USPS “city” name is not the same as the municipality (in this case, borough) name.
Absolutely. I was not sure why the current alt name guidance was limited to “no city” segments and kind of forgot about it when I gave my answer above. Maybe because in city disagreement areas Google will match the USPS name searched to the primary city of the Waze segment most of the time without an alt name. Still, that doesn’t mean it will match every time, and it can still be confusing for folks who search their postal address and then see the redirect with a different city. Also, a HN could be duplicated across a large city or borough (IIRC this has been a problem in Brooklyn), and it doesn’t hurt to just put the USPS name on every segment. It’s also a lot easier to do now, thanks to your script and others.
I wanted to post another example of how relying on CDPs for primary naming can be problematic. Not only is there the case of “the City of UC Davis” I mentioned earlier, but California also has two CDPs named “Live Oak”. One is Live Oak, a neighborhood of Santa Cruz that the Waze map helpfully calls “Live Oak CDP”; the other is Live Oak, an incorporated town north of Yuba City that the Waze map started out calling “Live Oak (2)”. If we harmonized the place names to both be Live Oak we’d have a massive smudge, as they are roughly 150 miles apart.
(Separate issue is the number of years it takes for Waze to realize that one of its original cities needs its name changed; the old stuff seems to hang around in the back end in perpetuity.)
Yeah, that’s a good point. There’s a similar situation in Ohio with a CDP and a village called Bainbridge. The village was labeled in Waze as Bainbridge (2), since renamed, after the CDP was renamed to Bainbridge Township. And as for the military base city name hack, I thought about that but forgot to mention it. They have their own rules, of course, and we can mention that.
So can we propose some specific text to evaluate, maybe something like these?
and
Perfect. Gives authority to local leadership while still providing some basic guidelines on analysis, and not too wordy or complicated. Two thumbs up.
Looks like we reached consensus here, so I have made the changes. As indicated above, I included “except for within [[Military Bases|military bases]]” as an exception in the language in each section.