Can someone explain the meaning of:
Filter by City (Yellow)
Nantong, INVALID STATE
Why ‘invalid state’ when there is nil function to add a state?
Maybe this is nothing to do with the script, but more to do with Waze?
I see very big problems ahead, in China it is: province, county, city, area, street.
Many cities have the same street names, some cities in romanised english (pinyin) are identical, thus Taizhou is a city in three different provinces… fun in the future indeed!
Daxigua.
Uploaded the beta v1.6.2 to Userscripts.org: http://userscripts.org/scripts/show/141050
Thanks for the small update Timbones.
I hope Waze can work on adding states/ provinces for China.
Simon
[Off-topic posts deleted - thank you for not trolling]
We’ve been waiting 3 years for this feature on World server, and it might be coming soon. 
Not a good sign, as I think this is a disaster already happened.
I guess an expensive database guru might be able to rectify this.
This ‘missing feature’ is an important task, thus I hope some posts like these gets some money well spent now, not ‘later’
Sorry for stirring the pot with my frustration.
Daxigua
Some small bugs associated with landmark highlights:
I noticed that in ‘highlight by city’, that this works great for segments, but does not work for landmarks. (They highlight the current city regardless of the state of the ‘invert’ button.) Can this be changed/fixed? It’d be a really great way to quickly identify landmarks that are improperly addressed.
If a user disables ‘Highlight landmarks’ and ‘Highlight by city’ is enabled at that time, landmarks that are yellow remain yellow until a user mouses over them (or unchecks ‘Highlight by city’ and re-checks ‘Highlight landmarks’.
Does the script attempt to read get.landmarks to grab any cities seen in landmarks, adding them to the list? In my area there’s a lot of ridiculous entries like for <no state>, or <Mexico>, or whatever…that would help vet these out.
Thanks! Awesome update, Tim!
I’d still love to see WMECH stop highlighting selfcon. It seems like an “error” when there really isn’t.
Alan: I don’t understand – is this a node connection (i.e. the purple or red highlight of a node) or the green highlight of a segment that forms a loop?
I have to disagree with this one. Selfcons allow the client to act in an unacceptable way. I’ll quote a specific example from my own beginnings with Waze. My normal route to work travels for a mile or two before reaching a T-junction. At this junction, Waze always wants me to turn left, as that leads to a route that is mostly major highway with good speeds. However, it is also a route with some tricky junctions driven by too many idiots who don’t pay attention to what’s going on, or are in such a hurry they think they can take whichever lane they like & then barge into the right lane at the last second. It’s the sort of thing I can do without to start my day, so I turn right at the T-junction and take a quieter route over smaller streets that is rarely slower than the other route.
When I first started with Waze, I would turn right and the same thing would happen every day. At the next junction my purple line would disappear and I would get no instructions. On checking, the route was, in fact, folding back on itself to proceed as if I had taken the left at the T-junction. The next instruction would be a turn right a mile further down that way. Waze would not stop doing this until I had disassembled & reassembled the junction to the right of the T-junction (I didn’t know about selfcons at this point). Eventually we got an update (they were much slower in those days) and Waze started trying to do the same at the next junction. :twisted: Same fix, long wait for updates and Waze started to route me round a block to go back.
That was fair enough. Waze didn’t like my route - I could accept that - but at least it was sensibly telling me how to go the other way. By the time I had gone 2 junctions up the “wrong” way, Waze would decide I knew what I was doing - presumably a recalc on the new route seemed reasonable by that point. But occasionally it would still think I could u-turn at the 4th junction. I just ignored that - until highlighting for selfcons became available and I found a selfcon there. Got rid of it and no more u-turns without instruction.
I have also cleared a couple of URs where the Waze-provided route showed this u-turn behaviour at a node that had a selfcon.
So, my problem with selfcons is that they effectively allow Waze to route a u-turn at the end of a segment you are driving on but the client has no instructions available to handle this manouevre. There may well be an argument that u-turn behaviour like this could be useful - but if it is, then the editor needs to show the selfcon arrow by default (without the use of scripts) and the client needs instructions to give to the driver. Unless that happens, I believe selfcons produce unacceptable and confusing routing in the client.
Selfcon is the way Waze is defining uturn on a 2-way segment. I’m suggesting that when u-turn functionality is released into the production editor, that this feature be removed from WMECH as too many people will think it is something to fix, when it isn’t always needing a “fix.”
If Waze is going to have a properly defined u-turn functionality, I have no problem with it. But I’ll make a few points about that:
First of all, we need to be told. This is the first I’ve heard that this behaviour might be deliberate. Of course, it might have been discussed in the champs forum, or I might have just had my head up my ass (happens frequently :lol: ) and I missed it.
Secondly, the arrows for these u-turns must be visible & controllable in the editor. And yes, once this happens, there won’t be any need for the script to highlight them. I’m sure it only does so now because selfcons are a hidden junction property that has a direct (and problematical) effect on client routing.
Thirdly, Waze needs to stop automatically creating these u-turns. There are areas where I have removed all the selfcons I could find and they are gradually re-appearing again. This can only be because people are actually doing u-turns (or 3-point turns, or going just around a corner and reversing out again), because there’s no way for us editors to create them. I presume Waze then creates a soft-allowed u-turn. However, just because one driver managed to do it does not mean it will be a safe or sensible manouevre. I know of junctions where u-turns aren’t prohibited and are quite easy at 1am, yet would be suicidal at 8am.
Lastly, the client needs to handle u-turns with an instruction like “at the next junction, make a u-turn” and a visual navigation instruction, rather than silence and a purple route that apparently comes to a dead end.
Given the numbers of them that I encounter and their random locations, I would suggest that, should this functionality go live, it would have to be preceded by a system-wide removal of the existing ones. Then we as editors can put in the ones that really should be there.
None of this is “complaint”, BTW. It’s just important points which I think might need some discussion. For that matter, there should probably be some discussion on whether u-turn functionality is a good idea or not. And it all may have been discussed already, in which case I apologise.
It’s in beta test, and like all things there, they aren’t announced right away but are slowly leaked. @WazeMapping tweeted it too.
Agree. This is the way it is going to be, and why I posted my request for wmech to be updated (maybe I should have put it in the beta forum only…)
Yes.
Agree, but not sure this is any different than other turns. Once set by an editor (locked, not a soft turn), they shouldn’t be auto-updated.
The app should update near the same time the routing server is updated. Right now, there is no u-turn instruction, so both need updates to handle it gracefully.
Can code be added to this script to identify segments that need addresses “addressed?”
Or as has been suggested in Re: New editor version - V1.0.12 [NA + ROW]
Presumably a good portion of the house numbers on the older streets are set / were imported with the help of the geocoding sources. Undoubtedly they need to be tweaked - prompted by UR’s.
Why, they aren’t currently used by Waze search? The address layer is just there to divert you from working on stuff that actually affects routing, or giving you something to do if there’s nothing left in your area. Typically, when Waze announces a new functionality is just around the corner, its 12-24 months out. Since they’ve yet to make any announcement that they plan on using editor entered addresses “just around the corner”, I think its safe to assume we’re several years out from them serving any purpose.
/Why yes, I am cynical.
It’s been posted about already: the search engine and app functionality aren’t built yet. It’s in process.
If Waze are going to insist on using self-cons for U-turns, then this script will indeed have to change.
However, I still feel that self-cons are a bug, and Waze should be doing it differently. An argument for another thread…
via mobile
Welp, I’m at a loss here. After installing 1.6.2 the script doesn’t work anymore. Nothing highlights, and there are no options under the dropdowns for cities or the purple highlight type. I uninstalled and reinstalled the script to no avail. Am I the only one having this issue? Haven’t seen any other posts on this, or how to fix it.
You may have to disable NoScript if you have it running, it may prevent running the script (or parts of it). Also check what options you have enabled, of course.
I definitely don’t have noscript running; I’ve never even used it before.
I deleted all the other extensions except for one related to Foursquare. It works and I just used it today. But the Highlights script is still not working. I deleted the cache, and the script itself and reinstalled — nothing changes.
I tried the WME Addons tool and it works, too. So it seems to be just this script that’s failing me.
I can’t see where it has been asked… Which browser, OS and versions of both are you running?