I have noticed that Waze has my home location correct, but instead of stopping on my street at the front of my house, it wants to end the trip in the alley behind my house.
How can this be fixed?
See http://www.waze.com/wiki/index.php/FAQ, item 28.
Okay… I did say the address is correct, so the end address, site, location, place is correct.
The only thing is Waze wants to end the trip on the alley behind the house rather than on the actual street the address is located on.
So the address is 1234 MyHome Street, not 1234 Back Alley.
If I am in my house and make Waze navigate to my house it will tell me to get on MyStreet (in front of my house), make a left at the cross street, then make a left into the alley (in the back of my house) and stop at my house.
Because the pin location is closer to the alley than the street the address is on. If you are in North America, Google pins are set back on the property. Do a Google search of your address and see where the pin is. Once Waze starts using it’s own addresses, and if they entered, Waze has a stop point for the street.
It can’t happen soon enough IMHO… the Bing “report a problem” dialog seems to do nothing, as does fixing the pin position on their maps… have to be very careful using web searches to get nav info.
I realize that there are likely other priorities for Waze than making the Waze street addresses live, but it would be sooo nice to be able to fix routing problems in an expedient manner and know that they’re fixed…
As I said, for some addresses in the city near me, the correct stop location for the address is the alley behind. There is no stopping lane on the main street. You must go to the alley to visit that address.
I have the same problem and I set the address marker much closer to the street than the alley. There is plenty parking on the street. I set the marker last week; the maps were updated yesterday and still today the same problem is happening. Here’s a permalink:
https://www.waze.com/editor/?lon=-75.50327&lat=40.60405&zoom=7&layers=TBFTFFTTTTFTTTTTTTTTTTTTTT&env=usa&segments=43450347
The address is 2014 W. Tilghman St., Allentown.
This makes no sense at all. Getting a person from one location to another should be a major priority in Waze. Since I and others are reporting the bug, I wonder why it still exists?
Waze trust on address locations from google maps. So they have to move the pin location. After google updates there map… Then Waze will take you to the right spot. (It is also needed that you remove/update your home/favorite location. in the Waze app. To renew the gps coords. recorded)
Thanks for responding. Although it might be fine for a map editor to get around the problem to regenerate their home location, it makes no sense for all users to have to do this to be able to use the address search function each time they need to use it.
I hope the Waze design team gives this issue a higher priority.
BTW, Stukje, your bug had me going for a few minutes. Good Job!
Not sure I understand this. But it’s pretty clear and well-understood from the documentation that Waze continues to almost exclusively rely on google in the US for address resolution.
Then of what use is Waze’s addressing function? I was under the impression that once we mofified an address it would override Google’s and that we would be responsible for any new addressing. I certainly do not want to put time and effort into this area if it is not effecting any results.
It is always more advisable to get the back-end of a system filled with data and functional prior to release to the front-end. We are slowly getting the Waze addressing system updated with more accurate locations (yes, at the same time we are also fixing google’s for them) so it will be ready when the production search engine is switched over.
What do you mean? If your address get displayed on the wrong place. Fix it at Google maps? So it is fixed before waze switched over and it stays fixed.
Unfortunately, it is not Google’s problem; it’s Waze’s. Although it’s true that Waze is using Google’s pin location, when routing to the same address on Google, the end location (street pointer) is correct. Waze is misinterpreting closest street, not Google.
From the amounts of UR’s continually being reported, this should be a very high priority problem, as this is a feature that most users want, where the destination location actually is.
Waze will often route to another street other than what was searched for due to another segment being closer, but that’s a separate issue. If Waze isn’t routing to the physically closest street, which is the current known and desired behavior and is generally working as designed, please supply such an example.
If you’re still talking about your “2014 W. Tilghman St., Allentown, pa” from earlier in the thread, I think it’s pretty clear the marker is closer to Utica than Tilghman. Move the pin much closer to Tilghman and it will be solved.
I did move the pin closer, else I wouldn’t have commented. I tried to move it closer on Google, also but it wouldn’t let me lock in on the address. It chose the entire block instead. I’m not theorizing the results. The results are clear. This is a problem not for me… but an indication of a greater problem across Wazedom.
Even Google Maps shows that the pin is closer to Utica. If you go in the move the address marker, it places the Streetview icon on Utica. :roll:
UPDATE: I moved all the pins for the 2002-2026 block to the Tilghman side.
I too have had a similar challenge as the house numbers some how cannot define the exact address. We have a Regional corporation which is responsible of issuing the numbers and I guess with the development being relatively new do not help either.
Seems to me that a short-term fix to a widespread problem would be to have Waze slightly modify the logic used to determine street location from Google GPS data. Where evaluating roads close to the the pin, it should assign some extra weight the road whose name is contained in the user-requested address. That way, if Side Road is 25m from the 1234 Main Street pin, while Main St is 30m, it could “weight” the 30m by say 33%, because of the name match, and consider it as 20m. Et voila, Main St is closer to 1234 Main Street than Side Road, and drivers are routed correctly.
The main problem with this is that the code/logic used does not take the user input into account at all. It relies only, and 100%, on the lat/lon returned by the search provider and nothing else. It would, accorinding to Waze, be a large undertaking to add this new logic. It would be simpler/less problematic, to use the Waze internal house numbers, when they activate it, because that logic is somehow already there because the data is internal and has street/address data already together.