The new Waze Wiki, aka Wazeopedia, is now live at! While this legacy wiki will remain accessible for the time being, it is no longer updated by the community. For the most up-to-date guidance, please visit your local Wazeopedia.

Please do not make any more updates to these legacy wiki pages, all future updates should be made in your country's local Wazeopedia.

Clock over a larger globe

Road names/USA/City names

From waze
Jump to: navigation, 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.

Error creating thumbnail: File missing

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.

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

Because many Wazers will search for a location by its postal address, U.S. community leadership has established an editing standard:

  • On segments which have "No City" set, an Alternative Name is to have the same street name and the city designated by the U.S. Postal Service

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.

Error creating thumbnail: File missing
In the image to the right, the city has now been added to the segment which the address is attached to.
Error creating thumbnail: File missing

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

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:

Every Door Direct Mail, a mapping tool from USPS, produces a map with ZIP Code boundaries:

TIGERWeb is an online service of the U.S. Census Bureau:

Questions and Answers

Why not just put city name into the primary segment data?

  • 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;
  • 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 boundary 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 the USPS city in the alternate street data is only for segments for which the primary address has the "None" checkbox selected for the City because it is out of a city or census designated place (CDP).

This is a lot of work. Who is going to be responsible for it?

There is not yet any 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.