In some testing I did in June, Waze definitely interpolated between confirmed HNs. It will not, however, interpolate odd numbers if only even numbers exist, and vice versa.
Edit: this interpolation will not happen if there are Google addresses on the street.
What do you mean with confirmed ? I ask because we donât have imported HNs, most blocks have just 4, manually entered, numbers. Two at the star, 2 at the end, odd in one side, even in the other. Something like this :
2001.........................2099
=========================
2002.........................2100
And we constantly have problems with the search engine defaulting to Google results.
Hi:
So it should be only necessary to put house numbers only one corner of each square, like this?: In this example, Buenos Aires, Argentina, house numbers go on each square from 0 to 100 / 101 to 200 and so on.
|||2001âŚ|||2101------------------------2201
|||==================|||==================|||âŚ
|||2002âŚ|||2102âŚ2202
Papo: we have another problem in Buenos Aires, I think the city name should be identical to the one we are searching in the app, if not it will search through google maps.
Where in the wiki is the best place to put this list of search precedence?
This is the culprit for this problem:
Note that this is a google result, but not an âaddress guessâ result.
If you put 207 milton rd maurice into google, the result is not an address pin/guess, the result is a business. And since two businesses are listed, Waze happens to be pulling from the wrong one.
Either fixing the wrong listing, or mapping the address pin for 207 in google, or letting 207 go back to being a âguessâ, would fix this issue.
Hi guys 
Hi and welcome to waze map editing! We have a vibrant community of editors here with lots of information. Which country/state do you edit in, Iâd like to point you to the information and people in your area who can get you acquainted with all youâll need to know to edit properly.
Hi there and welcome.
I have a house number that is not updating. The address is 34 Rue de Saturne, Cantley, Quebec.
I put in the address on September 9 and adjusted the road to trigger a tile update, but the Live Map still places the address in the wrong place (south of the intersection).
Tile updates are delayed. We have not had a North America update since data for the 6th.
Sent from my SPH-L300 using Tapatalk
It finally updated on the 15th (!!!) to the 8th !!!
And WME is still âglacially slowâ, so they must be running another update now.
Here is an example of an address search that seems to be going wrong. The app is ignoring a residential point place in favor of a google address pin, in contradiction to the original post in this topic.
There are two major problems here
For these two reasons, it was a complete waste of my time to create a residential point place in the correct location for the business located at 404 W Lincoln Hwy, in the shopping center.
If I want waze to get people to the proper place, I should stop editing WME and start editing GMM?
Same issue here. Ignoring residential pins that were added many many days ago for the google result which is incredibly wrong. App simply will not find my residential place on several I have checked.
Whenever someone notices a problem with address searching, where can they report it?
I see the problems constantly, but I have been mostly ignoring it.
So I am prepared to make several reports of specific cases where adress searching is not working properly.
Sorry, I totally missed this question!
Confirmed means a HN which has been nudged or manually entered by an editor â #2 in the Original Post. I subsequently learned that interpolation will NOT happen, if there are Google addresses in place for that street. In that case, each specific number must be entered in Waze for it to take precedence.
Yes, the City name must match, or results can differ.
On search indexing, does Live Map follow the same indexing as the app? A local editor found a discrepancy with 115 Freeport Rd, Brick, NJ.
If you search the address on Live Map, this pulls the direct Google result and incorrect location. If you search the app, auto complete results use the nudged HN. Shouldnât Live Map be using nudged HNs over Google data?
Live map uses predominantly Google results, for some insane reason. WME search uses a mix something like the results from the Waze tab in the app.
Within the past couple of months, I have seen quite a few situations where residential place points (RPPs) wonât save. With primary credit to ottonomy on point 3 below, I wanted to summarize some of the reasons that seem to cause an error on saving an RPP. I believe some of this behavior is new within that time period, but some may predate it.
In theory, it does not matter whether the RPP number conflicts with a HN, and usually this is the case. But in a few cases there seems to be a conflicting HN in a hidden layer, not visible in the editor (probably the HN index discussed earlier in this thread); when this is the case you get an error even if you delete the HN corresponding to the new RPP. However, if you not only delete it, but wait a couple of tile updates for the HN index update, then you can then add [i]both[/i] the HN and RPP (strongly suggesting that the original conflict wasnât due to a conflict with the visible layer of HNs). This process usually clears this conflict. I always find it useful to have the HN showing on the real building, if only for reference by editors, since the RPP is often some distance away and may not identify the building.
There is an apparent limitation on how far a RPP can be from the corresponding Google Pin (assuming there is one). This seems to be in the range of 200 meters, but this is just a guess from experience. If/as soon as you are able to move the Google pin, you can save the RPP. I havenât yet found a way to save an RPP too far from the Google pin, if Google wonât move the pin. This behavior seemed to begin sometime in the fall of 2015, I didnât experience it before that.
RPPs may not save if there are HNs on the segment and the corresponding drive points are out of order. I am not completely clear on the exact parameters that cause it to fail validation (it may be that itâs only if the HN that corresponds to the RPP has a drive point thatâs out of order relative to its neighbors, but anecdotally it seems broader than that). The fix is to first put all the drive points in order (and you may also need to wait for one or two tile update cycles). Then you can generally create the RPP, and then put the drive points back where you need them.
RPPs as well as confirmed HNs may be ignored if the street name or city on the RPP or on the Waze street does not match the ones on the Google pin. In this case Waze doesnât detect a match and therefore uses the Google pin. The fix is to change one or both so they match (preferably fix the one thatâs wrong!). I havenât yet fully tested the impact of alternate names, itâs possible that adding an alternate name on the Waze street to match Google may resolve certain situations.
If you canât get Google to move a pin, and need a drive point thatâs on a different road than the named road, and beyond the distance range from the pin for a RPP, you may be able to create a short segment of a road with the same name as the main road, and add the HN there (in case of certain conflicts you may need to start with a different name and then change it after adding the HN and saving). I havenât tested this yet and there may be unwanted side effects, but itâs on my list to try.
Thank you for characterizing some of the confusing HN and RPP problems weâve seen and heard about.
Points 2 and 4 taken together are very puzzling. Taken together, they seem to imply we can never hope to fix Waze address searching merely by editing the Waze map. We have to correct GMM addresses first. In which case - wouldnât it be more effective simply to work with the GMM address pins, eliminate HNs altogether, and ignore RPPs / leave them for those who want photos of their houses?
I wonder if these are bugs or features?
I think itâs a mixed bag. I have found it useful to work with GMM pins first, if the pin is far off. In Chicago, where i do most of my editing, on the other hand, itâs usually that the GMM pin is closer to the alley behind the address, and nudging an unconfirmed HN fixes the problem quite easily. As Iâve been monitoring misrouting issues others have brought into chat, however, my first question is always âis GM correctâ, and most often the answer is ânoâ. Despite some chastising from editors more senior than me, I recommend at least checking the GMM location first, because fixing it may save problems later, and doesnât close out any options.
I didnât mean to suggest that HNs or RPPs donât usually work, they actually do. Iâve confirmed about 100K HNs and had few problems with routings on those addresses thereafter, except when bad addresses are cached in reportersâ phones, which is hard to avoid. I use RPPs a lot with corner lots when the address is on one street and the driveway is on another. But I also have run into maybe a few dozen situations where theyâre hard to save, hence my post. Out of 100K, a few dozen isnât really that much. Theyâre most often in sprawling apartment complexes where the GM pins may all be clustered at the entrance. And Iâve only got a couple Iâm currently working where the techniques Iâve cited donât fix the problem; hopefully Iâll figure those out too.
I actually welcome the integration of GM and Waze, even at the HN level. Itâs better for everyone if we have a single source of truth. But GM and Waze have different purposes and we need further maturation in understanding and accounting for those differences, and features for Waze editors to represent them appropriately on the Waze map. I do think we as Waze editors need to be able to override GM endpoints in some circumstances, but those situations really arenât all that common. The controls on doing that are just not yet well tuned. I think Waze is taking some early steps toward merging the two databases, but there are going to be a lot of rough spots along that trail; these are some of them.
What Iâd really like to see is a shared Waze/GM database of HNs that include both the pin location and the Waze drive point. Those are two distinct needs, only one of which is covered by GM today.