Switch to full style
Discussion for the unofficial, community-developed addons, extensions and scripts built for the Waze Map Editor.

The official index of these tools is the Community Plugins, Extensions and Tools wiki page.

Forum rules

Discussion for the unofficial, community-developed addons, extensions and scripts built for the Waze Map Editor.

DO NOT START a new thread unless it is about a new idea. Keep discussion of existing tools within the main thread for that tool.

The official index of these tools is the Community Plugins, Extensions and Tools wiki page.
Post a reply

Re: [Script] WME Validator 0.4.9 (BETA) / 19.01.2014

Mon Jan 20, 2014 7:34 am

Just started playing with the tool. Looks very cool. Great work.

Re: [Script] WME Validator 0.5.2 (BETA) / 22.01.2014

Wed Jan 29, 2014 9:48 pm

AlanOfTheBerg wrote:
TonyTorrent wrote:Emmons Circle is the horseshoe with both ends connecting to Wolcott Hill Street.

Emmons Circle needs to be split into two segments. No two segments should have the same end points. It causes all sorts of routing problems, and misidentification of the actual route requested on URs, etc. It also causes issues with inability to locate the correct location when starting on that type of road.

This has been well documented in a few different forum discussions, which the Validator author provided links to earlier in this thread.

There may be some confusion between the different types of "same connections". Let me clarify:

  • Loop Roads: One Segment. End-nodes A and B connect to themselves. Routing issues identified and fixes exist in many scripts. Covered in Wiki
  • Routing to Same Segment: One Segment. I found a strange routing problem when you start and end navigation on the same single segment. I fully documented it in the forums under Same Segment Routing Problems.
  • Parallel Segments: Two Segments. Also called Horseshoe Roads. This situation is like two resistors in parallel. The end nodes A of both segments connect together and the end nodes B of both segments connect together. A real example is here. I also posed this question in the forum under "Same Connections" cause routing issues?

berestovskyy wrote:34. Same endpoints drivable segments
What is the problem? Two drivable segments share the same two endpoints: forum reference
How to fix? Split the segment. You might also remove one of the segments if they are identical: instructions
Severity: warning
Countries: any country

This entry is referring to the Parallel Segments/Horseshoe Rd example. The forum reference for 34 actually links to my forum entry that was asking anyone to actually confirm there are problems with this configuration in routing, but there was nothing conclusive. I did point out the other problem with routing to the same segment in that thread, so maybe people got confused what was actually a problem. There were comments this was a known issue with Cartouche, but not necessarily the current WME.

Today I sent a message to the Waze team on that specific issue. I will report back what they say relative to this issue. If anyone has any current routing issues they know about or can find any forum threads showing this is still a problem then let us know and we can add it to the Wiki best practices.

If there are no routing issues that we can still find today I realize this particular warning will help identify segments that lay on top of each other, but these Horseshoe roads are so widespread in suburban neighborhoods I think it will invite unnecessary editing to add a junction. Also if we do leave this in we need to be sure the "remove unnecessary junction nodes" option does suggest removing them. LOL

Re: [Script] WME Validator 0.5.6 (BETA) / 29.01.2014

Thu Jan 30, 2014 3:54 am

berestovskyy wrote:Thanks!
Let me know when you get an answer.

IMO for the Parallel Segments we can create more precise and reliable check, so I'll disable 'Same endpoints drivable segments' for now.

Sounds good. In the mean time I still think the stacked segments issue is a good one to solve mainly for properly setting restrictions. When I first started in Waze I did not read the instructions :oops: and created a bunch of stacked segments by mistake. Then I didn't realize I had turn restrictions on both segments that were conflicting and causing problems, but I did not know the roads had been stacked on top of each other.

Is there a way to detect the geometry for two parallel segments are essentially the same shape? Maybe we only need to find those with no geometry nodes because they are easy to create by accident and easy to be hidden. Segments with many geo nodes would unlikely be matched perfectly with another road.

Re: [Script] WME Validator 0.5.2 (BETA) / 22.01.2014

Thu Jan 30, 2014 8:00 am

AlanOfTheBerg wrote:There are definitely threads about issues with routing related to segments which shared the same endpoints. And this has nothing to do with Cartouche, as it doesn't do routing, so why is that even relevant to the discussion? The issue with the routing server has existed since the days of Cartouche. I doubt Waze will officially have much to say about it because they've never properly responded to the threads displaying the issue.

Don't forget this is also the reason why WME does not allow the starting junction to split a segment if the end junction is on the same segment. It's been built into WME since the very beginning to dissuade this type of loop from being created.

Related threads:

Thanks for the thread links Alan. I see there are circumstances where it looks like it could be contributing to the problems shown. So far all the examples point to the possibility this is the cause of the problems and I see where it could be, but have we seen any actual situations where a route is sometimes good and sometimes bad and then after inserting the junction it never fails again?

I am not trying to be argumentative, just fully understanding the facts.

I agree the Cartouche example made previously likely does not make sense for routing, but it was not my comment. I came into Waze after WME started, and I am not familiar with all the underlying code elements on segments that might have been set wrong with Cartouche that don't happen any more. If you say it could not affect it, I will not argue that. :D

As for WME preventing parallel roads, I just created two segments that connect in parallel (Test A and Test B) drawing from the endpoints of Test A with no problem. I then created another segment and then split it with a parallel segment (Test C and Test D) drawing from an endpoint of Test C and then into the middle of Test C with no problem. The only thing WME stops me from doing is creating a parallel road into the middle of a current segment requiring it to create two new junctions, not just one or none (Test E and Test F). https://www.waze.com/editor/?lon=-122.2 ... TT&env=usa Personally it feels like the prevention of the 3rd example is more of a side effect of a problem with their interface, than being intentional if they allow the first and second example. :lol:

I saw your comment from the Waze Mapping Support Twitter Feed about loops now needing 3 segments. https://twitter.com/WazeMapping/status/ ... 2890188801 It appears Waze does indeed believe this is a problem. What I hate is that is seems solvable on their side, but they are pushing this one back to the free workers in the community to fix the problem. :(

I will definitely keep looking at this one and report back if I find any other new information. In the mean time maybe it is better to have everyone split the parallel road as there is minimal down side even if that is actually not making any difference to routing. :mrgreen:

Re: [Script] WME Validator 0.5.7 (BETA) / 29.01.2014

Fri Jan 31, 2014 7:16 am

olestas wrote:BUG After solving No inward connectivity (RED) problem, segment still remains highlighted in red until I select it again or refresh map.

I agree this feels a bit annoying if it could be eliminated. I keep thinking there is something else wrong or my fix did not work.

olestas wrote:REQUEST And can segments located one over another or REALLY near be alerted as not connected?

Seems good if it can be done. Freeways and other roadways cross over each other without actually having an ability to allow traffic to connect between them. It should ignore crossing segments that are on different elevations. It could recommend the elevation be changed if they are not supposed to meet. I guess we could do that for roads that pass through each other on the same plane, but do not have routing between them (like we do with ramps and freeways).

Re: [Script] WME Validator 0.5.7 (BETA) / 29.01.2014

Fri Jan 31, 2014 9:40 am

berestovskyy wrote:Say if we have 500 segments at zoom 4, we have to make ~500x500/2 = 125000 comparisons (sometimes non-trivial). I'm not sure if we can optimize something here...

Wow. Maybe add it to your list of optional checks?

Re: [Script] WME Validator 0.5.9 (BETA) / 02.02.2014

Mon Feb 03, 2014 9:42 am

berestovskyy wrote:02.02.2014 v0.5.9:
- NEW for ALL: 'Unneeded name on one-way Ramp'

I could have missed the discussion on this one, but how does this determine it is unnecessary? I assume the subsequent ramps or streets are named.

However, I have seen plenty of very long ramps or when they are around corners where the initial exit sign naming is not the same as either of the secondary ramp split points.

Maybe this is only important if the initial segment length is too short and when TTS reports the first name it takes longer than the drive time to the next split causing the driver to miss the turn.

Re: [Script] WME Validator 0.5.9 (BETA) / 02.02.2014

Mon Feb 03, 2014 5:03 pm

berestovskyy wrote:
kentsmith9 wrote:I could have missed the discussion on this one, but how does this determine it is unnecessary?

If this one-way Ramp has a turn enabled to another one-way Ramp. Here is an example: permalink

Sorry, maybe the condition is not sufficient for US, so please let me know if I shall disable the check for US or add more ifs.

I am not sure what this means by your description of "turn enabled". Many of the one way ramps in the US will lead to other one way ramps with a turn enabled. I presume this is getting lost in the translation. ;)

Either way I do think we should consider disabling it in the US. I don't know of any situation where the name in the ramp causes problems except the point I made about short ramp segments possibly. In that case maybe we do some tests to see when it is too short and then you give the warning.

Re: [Script] WME Validator 0.5.9 (BETA) / 02.02.2014

Mon Feb 03, 2014 5:07 pm

Found a situation with a roundabout giving a warning "Same endpoints drivable segments." In this case assuming the reports that the routing engine has trouble with these by not starting people in the right place, a roundabout with the two segments going only opposite directions would force the routing server to only go through one way or the other. And worst case someone starting on the roundabout or ending on the roundabout can likely figure out the route in that circle.

Otherwise we have to add a node in the middle of one of the two segments on the roundabout. That seems like unnecessary work.

Re: junctions with drivable and non-drivable

Sat Feb 22, 2014 3:57 am

dbraughlr wrote:A ramp must be connected at both ends and the junction at one end must have a freeway/highway/ramp segment.

I don't think "junction at one end must have a freeway/highway/ramp segment" is true based on my knowledge.

Wiki - How to label the connector type wrote:Ramps in Waze should only be used for situations where two roadways have a grade separated intersection or if the situation matches one of the Exceptions listed below. {Note the exceptions are for Ramps at grade.}

Unless someone can identify the problem (which then can be added to the Wiki), it is certainly possible for one (Primary) Street to pass over another (Primary) Street and have a connector between them marked as a Ramp. In that situation a Ramp is fully legitimate, but not required.

I propose the Validator not restrict the roadway type on either junction of a Ramp, but I am OK with the number of connections being required.
Post a reply