herrchin wrote:

Done!

The new "City names on segments" section is missing from Wazeopedia, presumably due to timing of the wiki edit vs. Wazeopedia import? The new City names page came over fine and is current.

Good catch. I'll sort it out and confirm back here when complete.

The section and detail page have both been fixed. For some reason the three images did not transfer and had problems with their thumbnail, so I reuploaded them and they work fine now, but show me as the person who uploaded them.

For those of us without access to the thread you linked, can you please put the Q&A in here?

Michael (Kartografer) and I are going to be collaborating today/tonight on a draft, and will post it here for discussion ASAP.

OK, the text for the proposed guidance is below. It's also hosted with images on this userpage:

https://wiki.waze.com/wiki/User:Machete ... ove_search

Please do respond with any corrections/suggestions that could clarify my admittedly limited understanding of the issue. Also, Kartografer is proposing combining this with the existing guidance on duplicate cities for a more unified city page, so any thoughts on that prospect will be appreciated. Thanks!

----------

Editing city data to improve search

To keep city names from sprawling over too wide an area in the Waze app, in WME and LiveMap, editors follow standards of placing the city name on segment details only within the boundaries of the city polygon. That means many addresses on the map are in these “no city” areas, particularly in rural regions.

The search problem

An editor can create a Residential Point Place (RPP) in the correct location with an accurate address, but Waze may not route to the RPP if the city is not on a nearby segment. It will turn up under the "more results" tab in the app, but will be listed without a city and thus unlikely to be chosen.

Waze search defaults to best match of search terms, whether they're entered in search fully or selected from the autofill results. If the Wazer enters or selects a postal address and there is none on the Waze segment, Waze will go to its Google backup data that matches and will route to that pin. That’s not always optimal, especially in rural areas or other locations where the destination is some distance from the named road.

There are sometimes multiple city names in use for an area — a municipality or a Census Designated Place (CDP), in addition to the postal address.

But because many Wazers will search for a location by its postal address, U.S. management has established an editing standard to include the city designated by the U.S. Postal Service as an alternate on segments having no name, or a conflicting name, in the City field.

For example, these images show a discrepancy between Waze RPP and Google coordinates, and where the Waze app puts the search result. The example shown in the images is 10020 SW Grabhorn Rd, Beaverton, OR.

The solution

The city has now been added to the segment off the main road closest to the RPP. NOTE: In order to add an alternate city to an unnamed road segment, it’s necessary to put the street name of the address in the primary position, and then save, to get the option to add an alternate. The street name can be deleted from the primary after the alternate is in place.

The improved navigation result can be seen in the final screenshot from the app.

There are other standards in place for other purposes requiring adding other street data in the the alternate. The addition of the USPS data does not change any other standards but is in addition to anything existing already on those affected segments.

Identifying the correct postal city

Editors should use official USPS tools to check the city. If you know the ZIP Code, the city can be looked up here, or entering a city believed to be correct can be verified:
https://tools.usps.com/go/ZipLookupAction_input
Every Door Direct Mail, a mapping tool from USPS, produces a map with ZIP Code boundaries:
https://eddm.usps.com/eddm/customer/routeSearch.action
TIGERWeb is an online service of the U.S. Census Bureau:
https://tigerweb.geo.census.gov/tigerweb/

Kartografer wrote:TIGERweb from the US Census Bureau is one of the easiest ways to see both city (corporations and CDPs) and ZIP code boundaries, and I think the original Waze city layer may be based on its data. Just check the ZCTA box to see ZIP codes. Once the ZIP code is determined for an area, the default city can be found using the USPS ZIP code lookup tool on the cities by ZIP code tab.

Thanks for this. I'm hoping to hear input from others, too, on which tool(s) they find most useful. I have to admit, I lack sufficient practice with all of them to make a good recommendation, so I'm throwing them out there for discussion, for now.

Belatedly I'd like to report on some thoughts Tony shared with me. I jumped the gun and posted a draft, but he's tweaking it a bit before reposting.

But one of the key elements I need to make sure I understand: I thought this is not only for segments that have "No City" but may have something different from the USPS. That doesn't seem to be mentioned on the published page.

For example, Hawaii does not have municipal boundaries but uses CDPs in the primary. There is often a conflict with USPS, so an alt is needed there. My understanding was that was now an editing standard: USPS alts wherever the entry in the primary is "No City" ... AND when there is a conflict.

Have I misunderstood the guidance? Thanks!

As the poll and associated guidance are relevant to the us, this proposal should be made in the US wiki forum. Perhaps a forum mod can move this thread there.

ldriveskier wrote:For those of us without access to the thread you linked, can you please put the Q&A in here?

Here is the QA post quoted.

AlanOfTheBerg wrote:I have read everyone's comments and will attempt to summarize below some answers.

Why not just put city name into the primary segment data? a) Because city boundaries, which people will see on the map, will be smudged. A driver unfamiliar with an area may come into a "city" which has a primary name which is known, but which is not the mailing city. If the mailing city is put into the primary name field, the person may be confused and think they have arrived because the city name will show in the app map, even though Waze says they still have 20+ miles to go; b) Similar, but with the WME, and potentially livemap, city boundaries are important visual cues.

Why don't we just lock the city boundary and use the primary segment data? Because if you want to grow the city boundary, the only option we have today is to unlock the city and let the tile building process update the boundary. But now, since the primary name would be spread far and wide, the city boundry will be way off.

Why should we play with alt-names just to work around Waze? Because that's how it is set up right now and just like pretty much everything we do as map editors, involves working within the system Waze has.

Can't we just use zip code maps to update city? Not reliably. Zip codes can be assigned to more than one USPS mailing address city, and more than one zip code can be assigned to a city.

Is this going to be for everywhere? No. The use of alternate street data is only for locations for which the USPS mailing address is different from the data in the City field, regardless of whether the primary City field is empty/NULL or a different name.

This is a lot of work. Who is going to be responsible for it? I have no precise data, but it is likely that a good chunk of this work is very much rural, in areas with little need for higher lock levels. Most rural roads are going to be L1 or L2.

Is this going to affect every rural segment? Not necessarily. Only those which have USPS delivery, or are addressable. There are very remote rural areas which do not have USPS service, and therefore will likely not need any update.

Won't this result in a bunch of "duplicate" or repetitive data in WME to maintain? Possibly, yes. Unfortunately, working within the Waze limitations in WME and search engine is going to require that for some roads, we may be added 2-3 more alternate segment names just to add the USPS city.

Why are we doing it this way? Why doesn't Waze just make their search work properly? The core of the Waze search algorithm is based on google search and Waze segment data. They make tweaks and improvements to it over time, but so far, since this addressing issue was brought up 2+ years ago (maybe longer), there has been no fundamental change to the Waze search. In fact, founder Ehud stated in a US meetup that a search algorithm is so much work to build correctly and maintain, that Waze does not want to spend the time, money or energy to build their own, and are happy to stack the Waze matching process on top of the google search algorithm.

I made the address in the example be a link to the WME PL for the RPP. I removed the S from the httpS in the source links at the bottom.
See the change comparison here.