qwaletee wrote:Please see this new thread on loss of elevation data that may be due to JNF (or not!).

This is not a problem caused by JNF, but a problem caused by Features (WME backend) and propagation delay. JNF attempts to deal with the problems (data consistency and propagation delay) by issuing another data reload after successful saves. This issue has been around for about 2 years now, and has been referenced multiple times in this thread.

Jay91150 wrote:Is there any possibility in getting JNF updated to "fix" 'same endpoints drivable segments' in a similar fashion to how it fixes self-connecting loops, so that I can just hit one node of a 'same endpoints' with the 'qw' key combination and it'll automatically break the segment in question into two? Or is there another script/extension (for Chrome please ) that will do that?

It'd save me a huge amount of time getting rid of thousands of these segments in my city, rather than drawing a road intersecting the segment and then deleting it.

Yes, it's something I am working on, as well as updating the node removal bookmarklet to follow the same rules.

berestovskyy wrote:IMO we should split the segment with the lower road type (i.e. parking lot rather than highway), or the longer one, or the segment with the higher ID. That is the tie-breaker I'm using in Validator...

Split the longer of the two, else split the lower ranking Type, else split the youngest segment, else split one-way vs two-way, else split the highest segment id (it was created/imported later).

The first rule should almost always match except for special stacking hacks to make right+left turn restricted (and the mirror for rhd countries). The common match will always have a geometry point to split on, the uncommon will have to split on 1/2 total length if there are no intermediate geometry points.

doctorkb wrote:Can I suggest that lower ranking be split before longer?

If the short segment is a parking lot, it should still be the one to get a penalty over a street...

FYI all this connected to same node fix does is deal with a display problem in WME when drawing the route proposed by Waze. There is no actual issue being fixed by this in terms of end-user experience or routing.

doctorkb wrote:Ok -- but making the change (i.e. putting that node in there) can introduce a few things:
1. if it's on a corner (a likely place for a geometry node, where the junction would be created), there could suddenly be a "turn left" or "turn right" instruction when before there was none.

There are no instructions when there are no alternatives. That's in the Wiki btw.

doctorkb wrote:2. there will be an additional penalty introduced (at least until the routing engine gets better knowledge of traffic)

5s for 1-2 days from the first time someone transits the node, same as an edit delay.

CBenson wrote:Why will there be an additional penalty? Waze told us ages ago there was a penalty to pass every junction node, but later told us that if the node only connects two segments the penalty is "null."

We've actually tested that. There's a penalty until drive analysis processes a drive across the new node. After that happens and a tile build happens, the assume transit time does appear to become zero, but until that happens it seems to be the old 5s penalty from the dark ages.

CBenson wrote:While primarily a display issue, I believe there are some minor end-user experience/routing issues that are addressed as well. First, if the route begins or ends on a segment that connects with another segment at both ends, I think that sometimes the route is shown beginning or ending on the other segment. Second, if your route includes a segment that shares end nodes with another segment, if you deviate onto the other segment, it seems that waze does recalculate the route (admittedly not a significant problem as you end up at the same point anyway).

Perhaps. It would explain some of the "proceed to highlighted route" I occasionally get.

Updated and Chrome Webstorized.
Read the details, there's changed behavior and required action needed for closed loops when there's house numbers.

Version 0.0.9.0
This is now a Chrome Webstore Extension
Chrome Webstore

Checks WME's API to make sure used objects and functions exist and are the correct type. This works as long as function argument order doesn't change. Next step is to regex match on function contents to confirm arg order.

Makes cameras visible at zoom 0.
Updates keyboard pan amount by 1/4th the map view height.
Saves and persists turn arrow visibility and clickability between reloads/permalinks.
Saves and persists Full-screen mode.

Hooks into replaces 'q' (Disable All Turns) and does these actions on the selected node:

• Enables U-Turn and locks all turns at dead-end nodes. Changed Behavior
• Fixes any self and reverse connectivity issues
• Converts single node roundabouts (lollipops) and loops into a three segment loop. Any existing house numbers will be associated with the middle segment and MUST BE EDITED after save to update their stop point.
• If two or more segments are connected to the same two segments, it will split one of them. Same rules as SameNode.js bookmarklet.
• Terminates dead-ends
• Makes dead-ends two-way (only if both ends of the segment are visible)
• Sets the Type of a roundabouts using lowest of two highest rule and sets country/state if needed
• For UK sets Type of roundabouts using highest type excluding Freeway rule.
• Removes revcon (turns into wrong-direction of one-way), and selfcon (U-Turns at non-dead ends). Once the app has real support for U-Turns selfconf will be left alone
• Locks all turns at selected node.

That'd be great and all IF it were still a problem, which Waze claims it isn't and testing confirms that it isn't. The wiki is now out of date with reality and needs to be updated. This in regards to dead-ends only and the selfcon on the end node.

Alternatively you can ignore that it does this and simply wait until dead-end end nodes are removed from the model and are treated as always enabled by routing.

Sent from my Nexus 4 using Tapatalk

doctorkb wrote:As a third option, you could just remove the functionality, as it's clearly a problem with some locales (not sure the UK's issue, but may be different)... and as you mention "simply wait until dead-end end nodes are removed from the model and are treated as always enabled by routing".

Since this change is specifically by request of Waze staff I think it's up to you to come up with a convincing argument against which is something other than "but that's what we've always done because old JNF did it that way before I even knew there was an issue with dead ends."

Long ago before JNF was public it used to enable dead-end u-turns simply because you logically must be able to. After some time this revealed a problem with routing and a resulting change in policy because of the bad routing. That change also caused a different routing failure that we *still* have, but was agreed was acceptable given the alternative. With the original issue now resolved the current policy, which was the original policy, is back and works for *both* routing edge cases.

Sent from my Nexus 4 using Tapatalk