Get a sneak peek at whats next for Permanent Hazards on our April 7th Office Hours!
The place to discuss editing specifically related to house numbering (addresses): how to optimize locations, set stop-points, etc.
Post by NoelMoriarty
Isn't part of the issue here that postcode areas cover what can be a large area, even at the lowest level of granularity. Consequently Waze thinks my home location is 200 yards away from where it actually is, and whenever I pull up it thinks the journey is still in progress. Is there a way I can 'fix' the location and override it, for a favoured location? Or have I missed the blindingly obvious somewhere?
NoelMoriarty
Posts: 1
Send a message

Post by ploben
Bigbear3764 wrote: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.
Is there any estimate on when Waze will start using it's own HNs and stop points FIRST before looking to Google SECOND if it can't find it internally? I think this will clear up a few issues with HNs in Waze?
ploben
Posts: 29
Has thanked: 1 time
Been thanked: 5 times
Send a message

Post by ploben
CBenson wrote:My understanding is that when autofill results are generated, they are generated from the Google database and this is unlikely to change in the near future. However, if there is an exact match in the waze HNs to a selected autofill result, then waze will route to the waze stop point for that address.

If you complete the search, then waze first parses the search to determine if it is for an address or for a POI. If it is for an address, then my understanding is that waze does look to its own HNs first. However, it only looks to those HNs that have been added or modified by an editor. If it finds such a waze HN match it uses it first before looking to Google addresses. If there is not a perfect match, there may be results from both waze and Google shown on the waze tab.
It's unfortunate the auto complete doesn't look internal first, that would make sense.

I think the exact match has a flaw, in my other post about Quail Crossing vs Quail Xing, Waze still won't recognize my Waze pin in auto complete even though the address, street name, town is EXACT except the suffix.

On the topic of HNs that have been imported but not touched by an editor, don't these imported HNs have a stop point on the actual street? If Waze imported HNs for internal use why would they not then refer to them if they are searched?
ploben
Posts: 29
Has thanked: 1 time
Been thanked: 5 times
Send a message

Post by qwaletee
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.
qwaletee
EmeritusChamps
EmeritusChamps
Posts: 2939
Has thanked: 188 times
Been thanked: 958 times
Send a message
US Champ / Country Manager | State Manager NY, NJ, PA, CT, MA, RI, VT, ME, NH | Northeast ARC | Mentor | Responding to Map Issues

Post by qwaletee
AlanOfTheBerg wrote:
qwaletee wrote: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.
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.
As a developer, I find this hard to believe. I'm not saying it is trivial to program. But adding a parameter to a method or an attribute to an object? Meh. Even if it is buried under ten layers of function calls, there's usually an object with misc data used throughout the levels. Most frameworks support it easily.
qwaletee
EmeritusChamps
EmeritusChamps
Posts: 2939
Has thanked: 188 times
Been thanked: 958 times
Send a message
US Champ / Country Manager | State Manager NY, NJ, PA, CT, MA, RI, VT, ME, NH | Northeast ARC | Mentor | Responding to Map Issues

Post by qwaletee
AlanOfTheBerg wrote:
kentsmith9 wrote:Alan, do you know if this is already in bugzilla (I did not search yet)? Maybe we could get a bunch of us champs to vote for it to move it up? I waste a lot of time editing Google maps to fix this lame Waze issue, and in some cases I actually make the Google map data wrong by moving the house address pin too far away from the house just to get it away from the back street.
Waze already has the fix: internal house numbers. I don't think it makes sense for this to be in bugzilla.
Beg to disagree. Let them run a scrum for fixes and decide between implementing house numbers now and implementing an interim (and possibly not so interim) fix for the address lookup logic. Plus, they need a fire lit either way.
qwaletee
EmeritusChamps
EmeritusChamps
Posts: 2939
Has thanked: 188 times
Been thanked: 958 times
Send a message
US Champ / Country Manager | State Manager NY, NJ, PA, CT, MA, RI, VT, ME, NH | Northeast ARC | Mentor | Responding to Map Issues

Post by qwaletee
CBenson wrote:
qwaletee wrote: Plus, they need a fire lit either way.
I'm pretty sure that adding bug in bugzilla doesn't really result in any fires being lit.
That was Kent's point... to have a bunch of champs make complaints, in the (perhaps vain?) hope that it might actually elicit a response.
qwaletee
EmeritusChamps
EmeritusChamps
Posts: 2939
Has thanked: 188 times
Been thanked: 958 times
Send a message
US Champ / Country Manager | State Manager NY, NJ, PA, CT, MA, RI, VT, ME, NH | Northeast ARC | Mentor | Responding to Map Issues

Post by qwaletee
Where are you located?
qwaletee
EmeritusChamps
EmeritusChamps
Posts: 2939
Has thanked: 188 times
Been thanked: 958 times
Send a message
US Champ / Country Manager | State Manager NY, NJ, PA, CT, MA, RI, VT, ME, NH | Northeast ARC | Mentor | Responding to Map Issues

Post by russblau
arami76 wrote: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.
russblau
State Manager
State Manager
Posts: 1797
Answers: 1
Has thanked: 356 times
Been thanked: 668 times
Send a message

Post by slandrum
I'm having some issues where businesses (either POI or address lookup) show on a major street, but the businesses themselves are only accessible through parking lots that are not directly accessible from the street the address is on, you have to go to a side street or sometimes to a parallel street to get to the businesses.

Normally mapping parking lots solves these issues, but now I'm starting to run into issues where I have a couple of businesses that are physically closer to the major street than to any point in the parking lot, and Google won't approve me moving the business pin locations closer to the parking lot so that Waze can route appropriately. I agree with Google not approving me messing up their maps so that Waze can route, and I already feel awkward moving house pins when they aren't in bad positions to begin with. Waze needs to find a better way to resolve these issues.
slandrum
Posts: 362
Has thanked: 17 times
Been thanked: 53 times
Send a message
Orange County, CA, USA, Samsung Galaxy S3, Android 4.3 https://www.waze.com/wiki/images/2/24/W ... 2cones.png