Problem Segments? South Pasadena CA

[AlanOfTheBerg]

If Waze doesn't have the data from drivers taking this route, then it doesn't have the information required to make the correct mathematical decision. Waze needs all the data for all segments/speeds/time of day to ensure the fastest route is selected. If all the roads are correct and turns/restricted turns are correct, mark it solved and move on.

[CBenson]

I'm not sure if you gathered from my post that I was the one who submitted the UR. I drive through this intersection from various angles frequently, and the routing there is almost always odd.

Waze does keep distinct speed data for each segment for each exit path from the segment. Thus, the question becomes have you actually driven through the intersection taking waze's proposed turns. My experience is that if you do this a few times the odd routing stops.

[jemay]

So I tried Live map and could not reproduce the route in the direction you was heading, but reverse, it will travel the path you pictured. Nothing stands out.
The path travels from no city to city to no city and the street name change from Garfield to N Garfield (but that should not cause any issues) and on the dog leg there is a "node has 1 U-Turns." at Oak St & Avonrea Rd (so why would it route that way?)

So the next thing is it must be traffic???...

[ottonomy]

Could someone please examine these segments for some kind of issues that I can't see as a level 1? (rev-cons, low average speeds, etc):

https://www.waze.com/editor/?zoom=5&lat ... 1,62768496

When traveling north or southbound on Garfield Ave through this intersection, Waze wants to route around this intersection, using non-primary streets (note my UR below, surrounded by system generated errors of the "Most users did not follow the suggested route" variety). There is no apparent advantage to this bypass, even at peak rush hour. Especially when headed northbound on Garfield Ave, veering right onto Atlantic Blvd/Los Robles Ave, rather than continuing straight on Garfield, is actually the more heavily travelled route, and more likely to be backed up. The Waze suggested route as seen in my UR here is about the worst way I can think of to traverse this intersection.

GarfieldAtlantic.jpg (57.81 KiB) Viewed 255 times

[ottonomy]

If Waze doesn't have the data from drivers taking this route, then it doesn't have the information required to make the correct mathematical decision. Waze needs all the data for all segments/speeds/time of day to ensure the fastest route is selected. If all the roads are correct and turns/restricted turns are correct, mark it solved and move on.

Thanks, Alan. This is a very heavily travelled intersection, so there should be a lot of historical data on those segments. I don't see any evidence that any of them have been deleted and recreated recently. Admittedly, I have a less than perfect understanding of what may affect segment speed data. I'm not sure if you gathered from my post that I was the one who submitted the UR. I drive through this intersection from various angles frequently, and the routing there is almost always odd. I've poked around in WME and found nothing obviously wrong, so this time I created the UR with the hopes of attracting the attention of someone with the editing chops to figure out what's up there.

Does this always happen, or was this a one time deal?

I would say that at least 3 out of 4 times I drive through there, the routing is strange. It's not always the same, either. Sometimes it wants me to take this route:
https://www.waze.com/editor/?zoom=6&lat ... 16,4759302
... or a variant of one or the other when going southbound.

[ottonomy]

Waze does keep distinct speed data for each segment for each exit path from the segment. Thus, the question becomes have you actually driven through the intersection taking waze's proposed turns. My experience is that if you do this a few times the odd routing stops.

As it happens, I have on more than one occasion accidentally taken Waze's route through there. I'll be heading somewhere generally to the north, hear the prompt say to keep right onto Atlantic Blvd, follow the instructions without thinking (that would be the correct route for a number of places I go), and then I hear the instruction to turn left onto Oak St, and it hits me... What the...?!? Not again!! And then I sit there interminably on this segment, which always gets jammed up by In-n-Out Burger drive-thru traffic and the majority of drivers who wish to head eastbound on Huntington Dr from there. This is why I was hoping that someone could actually see the speed data and determine if one of these segments is fouled up somehow. Perhaps I have misunderstood references to this possibility elsewhere in the forums.

So I tried Live map and could not reproduce the route in the direction you was heading, but reverse, it will travel the path you pictured. Nothing stands out.
The path travels from no city to city to no city and the street name change from Garfield to N Garfield (but that should not cause any issues) and on the dog leg there is a "node has 1 U-Turns." at Oak St & Avonrea Rd (so why would it route that way?)

So the next thing is it must be traffic???...

This is one reason why I never feel that I can count on Live Map to produce an accurate representation of the route the client will suggest. I know that they are supposed to use the same routing algorithms, but there's something else in the soup that causes them sometimes not to jibe. South Pasadena, San Marino, and Alhambra meet like jagged puzzle pieces at this intersection. That's the reason for the (correct) change from Garfield Ave to N Garfield, and for the segments with no city names. Address numbers are chaotic around there, different in some places on opposite sides of the street, postal codes disagreeing with city boundaries, and so forth. It's no wonder navigation is a mess. So the only reverse connection you found was on one of the side streets?

[ottonomy]

I looked at it and couldn't find anything wrong. I know a lot of the Sr editors hate deleting segments, but I think it might be a good idea to delete and redraw that section of roadway and see if that fixes things. Since that's a pretty heavily trafficed area, the speed data should be reset fairly quickly. And besides, its not routing right anyway.

We've seen before that some segments/junctions appear fine in the editor, but are corrupted in the back end.

I opened up the client and panned over to that intersection. It took less than a minute to find a couple of Wazers passing through there, so I've taken your suggestion, with the knowledge that deleting segments is NOT something I want to do without careful consideration. In this case, there should be fresh speed data in no time. I knocked out the two most likely culprit segments and recreated them.

IMG_1992.jpg (23.94 KiB) Viewed 128 times

The section of N Garfield Ave that Waze was avoiding had a couple of oddities in its naming, compared to its connected segments (alt name "Garfield Dr" among other things), so I took care of that too, though I'm sure that wasn't the source of the weirdness. We'll see what happens. I should have a chance to test it out within a day or two after the client map is updated.

[shawndoc]

Does this always happen, or was this a one time deal?

[shawndoc]

I looked at it and couldn't find anything wrong. I know a lot of the Sr editors hate deleting segments, but I think it might be a good idea to delete and redraw that section of roadway and see if that fixes things. Since that's a pretty heavily trafficed area, the speed data should be reset fairly quickly. And besides, its not routing right anyway.

We've seen before that some segments/junctions appear fine in the editor, but are corrupted in the back end.