Just a heads up, all, about the nature of the 'route ignored' URs, as well...

Some of the history for these goes back at LEAST a couple weeks. One UR in Tukwila, WA I solved was Waze showing an ignored route onto a street that I moved/fixed on December 4, because a new road opened. I would guess that once this first round of them is dealt with, new ones will probably use more recent data. Just be careful of what Waze thinks it's routing onto to see if it wasn't already addressed some days/weeks ago.

shawndoc wrote:You only need to check the marked junction to make sure the turn restrictions are set properly. I'm finding the majority have some sort of mistake.

With this type of automatic error, you need to check further down the route the user(s) did take as another turn (or series of turns) they took could be incorrect, or even segments with the wrong direction.

I've found having solved a couple dozen of these that it's more useful checking the route Waze wanted a user to take, although checking both is valuable.

Checking the user's route will give you a sense for where most people go when they think they know better - and in a situation like this, sometimes they do! And, as the OP said, you can find turn restrictions at the intersection or a bit down the road on the green routes...

Checking Waze's purple route though can take a little more digging, but in my own experience I'm finding that more than 50% - maybe even 75% of the time, there's a problem a short distance away from the intersection (3-5 segments) that explains Waze's choice. Often the UR will only have the first segment or two's instructions in the error...which isn't a HUGE problem; it just means that usually you'll be looking in 'the neighborhood you were pointed into'. In those situations, I've seen things like this in the purple segment directions:

* Neighborhoods Waze wants to go into (to cut off distance), with a 'Dead end' sign that, while they had other ways in and out than the one, clearly they're not meant to be used that way (think 'two track dirt road or other clearly 'not streets'), which I marked as 'parking lot roads'.* U-turn possibilities that are really just somebody's driveway (I delete those if they're short stubs)* Streets Waze wants to use marked as two-way but actually one way* Speed gone to hyperspeed plaid on a segment inside Waze's choice, meaning it's favoring it because of a bad segment

That said, it'd be useful if these URs could show...how to explain...purple routes the same way it's showing the green ones, maybe 3 segments out. Then we can see if Waze is always pointing in one single direction, or if it's just going 'wherever' after that.

By the way, I just want to take a moment to say to Waze - although there are always things that can improve, the new 'ignored route' UR is a huge plus!

In all of the URs I've looked over, I've almost always found something that makes me say 'Oh, man. Yep. That's just wrong, and that's why the route did that.' The automated UR is finding things that in an ideal world, a user would report, but they don't always.

jwkilgore wrote:Also, I'm personally generating those errors every day. I keep my auto-routing on to check the voice prompts. Waze almost ALWAYS routes me down the interstate to get home. It *might* be quicker during rush hour (I doubt it), but generally I'd rather casually drive down surface streets (speed limit 35-45 with occasional red lights) than fight through aggressive bumper-to-bumper freeway traffic (actual speed 35-45). So 2-3 times every evening I ignore Waze's suggested route. Unless I'm leaving work late and rush-hour traffic is cleared out, and THEN I take the freeway.

Coming in to work, I have my work address as my main office address. But I park in a parking garage a few blocks away on a one-way street. I assumed Waze would eventually figure this out and learn my preferred route, but it's been 6 months now and I get re-routes 2-3 times every morning.

Heya. I'll likely not be able to fix anything personally, but can you give me a zoomed out permalink of the general area you're working in? I can likely offer suggestions on what you can do as an editor to mitigate the 'always on the Interstate' problem. I've done work in Seattle metro to help this.

deadeyye wrote:Is Waze aware of following bugs in editor?-not being able to edit segment which i have full right to edit, like editor don't see my permissions. After clicking some faraway segment and getting back, this sometimes fixes (and i can edit again), sometimes i have to reload editor, sometimes it keeps being broken and i can't edit for long time. The segment is not locked or edited by higher-level editor. This bug happens often, say 1 for every 20 times i edit sometimes.

-not being able to select country. After adding new segment country list is empty (it should be filled with "Poland"), not allowing to fill in address. This bug seems like waze don't download country list, and waiting doesn't help.

Both bugs happens randomly, sometimes zooming out and in helps, sometimes reloading editor helps, sometimes bug is there even after reloading. Looking in local Polish subforum, many other editors have encounter those bugs too. I'm using Chrome and edit Katowice area, but editors from different areas also had those bugs.

Try turning off your landmarks layer, then reloading the page. There are bugs with landmark layer editing that sound like what you said...

I started scrolling further away from major developed areas, and this is what I got. This is going to take FOREVER to clear, and since they are UR's, its going to be tough to find actual User Requests mixed in with all the auto-URs.

This actually is a step up from not being able to find these segments at all except by random scrolling (then hitting 'I can't save' errors if you're unfortunate enough to save a segment against one of these), and it wasting even more of editors' time. It'll take 'forever' to clear, yeah, but...we also will be able to see exactly where the segments are to get rid of them. ...I think I can live with that.

Besides, the Portola Valley problem, since it spans multiple states, can't be fixed with a simple batch change, unless we're just going to change everything to 'other/null' state, which would cause even more pollution problems - or if they can be selective about which state to put on which segment, which as we know is probably difficult because there aren't 'firm state lines'. Maybe it's time to just lick this thing as it is.

EDIT: On further thought? If this is the best solution possible to hit these smears (and it may be!) maybe IGN can be pushed onto these? I'd be fine with that, too, since almost all of them are going to be 'Just make them 'No city, [State]', and save without any other changes, then solve the UR. Done.'

AlanOfTheBerg wrote:It sounds like the operation is mostly working as designed:

1. Segments incorrectly labeled with "Portolla Valley" were to be automatically updated to the correct city they are in, if that city could be identified2. Segments were set to "no city" if the city could not be positively identified and a UR posted.

Only #2 was supposed to generate a UR, but perhaps, ALL of them generated a UR? That let's us verify them at least, to make sure the update process got it correct.

Does this mean some or most of the PV smudge is supposed to be gone? I've got some up in Trinity county and near Mendocino, still. Maybe the script is still running?

skbun wrote:Does this mean some or most of the PV smudge is supposed to be gone? I've got some up in Trinity county and near Mendocino, still. Maybe the script is still running?

I spent an hour today manually cleaning up PV segments in the SoCal desert today. So no, they haven't gone anywhere.

Alas, if true. Did you see the trick about reducing the size of the Chrome browser's zoom, so WME Addons can maximise the number of segments it can see at once, at zoom 4? (You can then select all segments with PV city using the addon, then edit with standard WME city editing on all segments, set to none, and they're gone.). At least that way it can be done 9 square miles at a time rather than about 2.5.

shawndoc wrote:Just an update, I went back to two of them and turned the city layer on. It looks like there's either a smudge, or just the way Waze handles city borders, doesn't like the curvy twisty borders that sometimes crop up where multiple cities merge together.

I'll need to poke around later, as well as try to figure out what the official border lines are.

If anyone has a resource for finding the exact city borders in California cities, I'd appreciate it. (Real borders, not mailing address/zip code borders, which often don't match the actual city limits) Update: Here's a city zoning map from one of the cities, to give you an idea of how messy things are in this area.https://www.cityofindustry.org/pdf/zoningmap.pdf

Before you proceed too far, some city borders as they exist may not be completely editable.

I believe this is still true - part of the problem with city border management in the United States is that there are technically two city layers. There's the editable one that we can use to create or expand existing cities (that's how you get cities like this one: https://www.waze.com/editor/?zoom=4&lat ... TTTFTTTTFT

Then, there is a non-editable layer whose borders came from (my best estimate) the 2000 Census. Cities on this layer cannot be deleted nor their borders completely contracted. (They CAN be expanded). An example of THIS one is https://www.waze.com/editor/?zoom=2&lat ... TTTFTTTTFT , Lea Hill (which was annexed in 2008 to Auburn). I've put all its segments into Auburn, but as you can see, it doesn't completely want to disappear.

I think to make city border management of existing 'sticky' cities into a real going concern, the 'sticky' city layer would have to be let go, and all city borders would have to be (completely) generated by the segments with their ID. It could likely be done, but Waze would have to be the ones to make that happen.