Waze forum

This is a strange one. I found a street in San Jose where a UR said an address was going to the wrong street. Assuming it was our normal GPS routing without accounting for the street name I tried to fix it, but found this problem was not exactly the same. House addresses 340 and 338 on Bautista Place in San Jose, CA will show the correct destination with the checkered flag, but they route to a street that is a long way away from Bautista Place. You can see that Bautista Place is actually between the house and the destination where Waze sends you.

You can see the other addresses on that same block all route correctly. I eventually checked all the addresses on that image, and only the three marked in red came up wrong.

The 309 address is suspect as it is close to the other road Dupont St, however the actual GPS location on Google Maps shows it physically closer to Bautista Place.

I thought the problem was forced vs not forced addresses, but that was not the case. Both forced and non-forced addresses produce both results.

The only other data you can see here is 340 and 338 are possibly the farthest distance from Bautista compared to all the other addresses. Note that 338 was further south when I first ran the test and found the failure, but I moved it so I could see the address number.

Also 300, 313, 320 and 350 do not exist as an address, but Live Map will navigate correctly to those locations on Bautista Pl. However 307 also does not exist, but it fails like 309 (which is real).

Something I am not understanding is why some addresses on the right of Bautista are required to be forced and others are not. I wonder if that relates to our particular issue. Maybe there is something wrong with the Bautista Place segment in the database somehow.

Also since 342 works fine, I just need to move 340 and 338 closer to Bautista on Google Maps and Waze.

Has anyone else seen this strange behavior?

kentsmith9 wrote:House addresses 340 and 338 on Bautista Place in San Jose, CA will show the correct destination with the checkered flag, but they route to a street that is a long way away from Bautista Place.

This looks like Waze can't route properly because these two are located most closely to the disconnected walking trail. This is a long-standing issue which was recently re-discussed in a lengthy thread, and another reason why walking trails can be summarily removed even if they otherwise are mapped ok.

kentsmith9 wrote:Something I am not understanding is why some addresses on the right of Bautista are required to be forced and others are not.

This I can't answer other than it relates to how Waze thinks the street should be set up, numerically-speaking. The "ordering" for the US is based on the stop-point position on the street. It also looks like some addresses show as "forced" but if you adjust them only slightly and do not disturb their stop point position, they sometimes will save without being forced.

kentsmith9 wrote:344 and 311 are closer to the walking trail than Bautista, but they route fine.

344 does definitely look closer to the walking trail. I wonder if there is some minimum threshold where routing will use a street if the distance is within x meters?

311 I don't agree is closer to Bautista. It looks very close, maybe a tie, so I'd say Waze picks the walking trail in that case and "fails."

kentsmith9 wrote:Something I did notice, when the Live Map tries to route the 3 that fail, it takes almost 2x the time for it to come up with the route. The others that are correct have a route in a relatively quick time.

I don't remember from the other thread how livemap acts, but I know in the app, in these cases where a disconnected segment is closest, that routing will outright fail. Possibly if this is in the app, that it simply times out.

I think @CBenson might have more to add to this as he was in on the other thread. In fact, I saw him skulking this area of San Jose just now...

kentsmith9 wrote:Not sure you are correct on 311, but in the mean time i moved the walking trail so we can revisit this site in a day or two when the live map changes.

Make sure you are comparing WME production editor search result pin placement, not the house number.

kentsmith9 wrote:Ah. Good point. I was not. I also assume that the flag placement in live map would be the same result you are describing in WME, correct?

They should. And the address pin should match with maps.google.com too. It's not too often they are different.

kentsmith9 wrote:I see from the prior finding from CBenson in the Walking Trail thread that Waze is actually wanting part of this functionality and I for the life of me cannot see how this makes any sense. If they are using walking trails as part of the route to get to a final destination, why not consider the driveways and parking lot roads that are effectively doing the same thing. Maybe because they are not named it wont work?

I am not sure that Waze wants this as functionality for walking trails, as much as it is functionality we already know but it causes us issues in this case: Waze routing code is (desperately) programmed to put the destination point at the nearest spot on the closest segment to the lat/lon of the search result. That this segment isn't reachable from any other segment is where the routing code runs into trouble and fails miserably.

In the case of house numbers, once Waze uses internal addresses, this is "solved." However, the problem will still remain for any other search provider result, until they change the code to take the expected street name as being significant in determining the actual end point for routing.

CBenson wrote:...it sure seems to be intended to address the situation where the internal database has number associated with the walking trail.

It's pretty rare, but there have been examples in the forum, I think in Europe, where house numbers were being added to walking trails in complexes. Apparently there are actual named "streets" but are non-drivable.

I was skulking there. I believe this is routing based on the walking trail. But I can't explain the difference in routing between 340 and 344. The last I was told is that if the pin is closest to the walking trail, then waze will route to the closest point on the road network to the end of the trail. There were plans to change this to route to other roads that are close to the trail. The last time I asked I was told (on Jan. 13) that the change had not been implemented, but would be part of the next routing server upgrade for which there is not yet an ETA.

Some of the prior walking trail discussion was here.

I did send off an inquiry asking for an explanation for the difference in routing for 340 and 344.

That's not the impression I got in my communication with Amit. My understanding is 1) this behaviour was recently added to walking trails (seems boardwalks also) within the last 4-5 months, 2) although not expressly stated, it sure seems to be intended to address the situation where the internal database has number associated with the walking trail. Waze needs to decide and tell us how routing with the internal addresses will work when a address number is associated with a walking trail.

But as we touched on waze is clearly struggling with how to handle stop points that are not associated with the named street in the address. So far we can't put a stop point where you should drive your car if that point is not on a segment with the name of the address.

Just the collective data. But I thought getting using the internal addresses was a priority. There also is some talk over here that they are used more than I thought.