Page 1 of 1

Incorrect behaviours in WME Toolbox

Posted: Mon Apr 14, 2014 2:40 pm
by Webs101
I have two issues that I wanted to separate from the main WME Toolbox thread because on is significant and should stand out on its own.

I'm using WME Toolbox in Chrome in Mac OS 10.8, if that matters.

First, the easy issue: Toolbox won't load after I log on to Waze to do my editing. It only loads if I'm already logged in. I need to refresh the page once logged in to get Toolbox to load.

Now, the major issue:

I spoke with Yigal of the router-server team at Waze about this to get confirmation since accurate info isn't easy to separate from inaccurate info in the forums and on the wiki.

It concerns segments that share endpoints (RTSEs), like these, but it also applies to little loops at the ends of dead end streets, of course:

http://nyveen.surfzen.com/Wazeloops.PNG

The routing server recognizes RTSEs as two separate segments. The client app, however, defines segments by their endpoints and cannot tell the difference between RTSEs. The result is errors in routing that can only be avoided by placing an extra node on one of the segments, like this:

http://nyveen.surfzen.com/Wazeloops2.PNG

We need to do that during map-editing and it needs to be made concrete in the wiki. (I tried editing the wiki myself but it keeps throwing errors at me.)

Here's the problem.... When you use WME Toolbox to "suppress unneeded junctions" (the broom icon), it deletes those necessary extra nodes. That behaviour needs to change.

Re: Incorrect behaviours in WME Toolbox

Posted: Mon Apr 14, 2014 3:33 pm
by CBenson
This is a fabulous, succinct explanation of the phenomenon that we have been trying to explain for some time. Glad to see some tangible benefits from the meetup. By any chance did Yigal confirm that this is true for roundabout segments that share endpoints as well?

Re: Incorrect behaviours in WME Toolbox

Posted: Mon Apr 14, 2014 3:58 pm
by CBenson
Webs101 wrote:We need to do that during map-editing and it needs to be made concrete in the wiki. (I tried editing the wiki myself but it keeps throwing errors at me.)
Which pages need updating? Should we have another discussion in the Wiki Updates and Discussion subforum?

Re: Incorrect behaviours in WME Toolbox

Posted: Wed Apr 16, 2014 8:35 pm
by GizmoGuy411
Was that what you were talking about when you came over to talk to Yigal?
Now I wish I had been eavesdropping as I was sitting next to him.

Since you already spoke with Yigal, maybe you can reach out to him by email to get the correct answer to CBenson's question.

Regarding the Wiki, I would re-post pertinent information in the forum thread for the Wiki, once you have all the answers. Or post now with what you know now and state that you are seeking more info from Yigal.

I do now know Yigal's email address, but I'm sure you can either get it from Amit or Noam, or just ask them to forward your question to Yigal. If you ask via PM, you should contact Noam.

Re: Incorrect behaviours in WME Toolbox

Posted: Mon Apr 14, 2014 5:39 pm
by OyyoDams
Webs101 wrote:First, the easy issue: Toolbox won't load after I log on to Waze to do my editing. It only loads if I'm already logged in. I need to refresh the page once logged in to get Toolbox to load.
I know, and for now I won't fix it. The reason is your login information is needed to pull Toolbox code from the server, so if you're not logged Toolbox doesn't load. You have to be logged when loading the editor to get Toolbox working.
Webs101 wrote:Now, the major issue:

I spoke with Yigal of the router-server team at Waze about this to get confirmation since accurate info isn't easy to separate from inaccurate info in the forums and on the wiki.

It concerns segments that share endpoints (RTSEs), like these, but it also applies to little loops at the ends of dead end streets, of course:

http://nyveen.surfzen.com/Wazeloops.PNG

The routing server recognizes RTSEs as two separate segments. The client app, however, defines segments by their endpoints and cannot tell the difference between RTSEs. The result is errors in routing that can only be avoided by placing an extra node on one of the segments, like this:

http://nyveen.surfzen.com/Wazeloops2.PNG

We need to do that during map-editing and it needs to be made concrete in the wiki. (I tried editing the wiki myself but it keeps throwing errors at me.)

Here's the problem.... When you use WME Toolbox to "suppress unneeded junctions" (the broom icon), it deletes those necessary extra nodes. That behaviour needs to change.
You're totally right, this is a bug. I've already added filters to this function, but this case wasn't handled. I tried to fix it, but before releasing it to all users, can you test it on the beta editor ?

Re: Incorrect behaviours in WME Toolbox

Posted: Mon Apr 14, 2014 5:47 pm
by OyyoDams
Webs101 wrote:
You're totally right, this is a bug. I've already added filters to this function, but this case wasn't handled. I tried to fix it, but before releasing it to all users, can you test it on the beta editor ?
No, I'm not in the beta. I'm sure somebody else could, though.
Ask for it ;)

Re: Incorrect behaviours in WME Toolbox

Posted: Mon Apr 14, 2014 3:45 pm
by Webs101
CBenson wrote:This is a fabulous, succinct explanation of the phenomenon that we have been trying to explain for some time. Glad to see some tangible benefits from the meetup. By any chance did Yigal confirm that this is true for roundabout segments that share endpoints as well?
I didn't ask about roundabouts but I think this would apply there, too.

Re: Incorrect behaviours in WME Toolbox

Posted: Mon Apr 14, 2014 3:59 pm
by Webs101
I tried adding a section to the "Best map editing practice" page.

https://wiki.waze.com/wiki/Best_map_editing_practice

Re: Incorrect behaviours in WME Toolbox

Posted: Mon Apr 14, 2014 5:45 pm
by Webs101
You're totally right, this is a bug. I've already added filters to this function, but this case wasn't handled. I tried to fix it, but before releasing it to all users, can you test it on the beta editor ?
No, I'm not in the beta. I'm sure somebody else could, though.