User randomly adding weird "doglegs" to turn lanes

Not going to go into detail other than to post a couple of many edits this user has been doing. I have used these intersections many time and routing has been great. This not only looks ugly but there is no need for these modifications.

Changeset: 148364188 | OpenStreetMap

Changeset: 148325203 | OpenStreetMap

the changes made to this intersection is a joke

OpenStreetMap

this is a very very complex intersection that not only looked very neat and tidy but also routed perfectly. Now it looks like a 1 year old randomly moved lines around

Going out on a limb here, but I suspect the user’s edits are to work around the issue of OSM routing engines incorrectly allowing “U-turns” in dual carriageways. This happens when the short road segment between carriageways allows the routing to turn right, turn right again in 10m, and continue.

By the username, it is likely to be related to Route Planner | NHVR

It may be ugly, but it probably solves the issue of semi-trailers (and cars) being routed incorrectly. I’d love to test examples of routing before and after the edits.

The OSRM and Valhalla currently have not caught up to these changes so they depict how routing was before the changes. Through all my “testing” and times a have used these intersections while under navigation I never experienced any of the issues you have described although I do understand what you are saying and was my initial guess as well.

Looks like they just made all the junctions converge on the road rather than the footway crossing

added another intersection I cant believe this editor is messing all these complex intersections up

Have you tried to politely write changeset comment about problems with their edits?

Or are you asking others to review their edit?

Or are you asking others to write to them?

Exactly which part of achavi - Augmented OSM Change Viewer  [attic] Changeset: 148325203 | OpenStreetMap ( where I see you commented) is problematic? (I fixed some minor geometry issues there)

3 Likes

Didn’t check the third junction as there were a couple of changesets and it’s more diffucult to show on overpass. The first two are correct, I’m afraid. It looks like previous version incorrectly splitted lines where the new lane begins, not where the physical separation started. They also removed uncessary lines on the first junction - in short, the less lines there are on map, the better for navis. So in most cases you would prefer splitting lanes only if there is some sort of barrier.

While I do prefer “less edgier” links and would problably change the geometry in some cases, I don’t see an error there. Maybe there are some weird tags on them, but generally it’s better than it was, but still some work to do.

A mapper in my region has been doing the dogleg style since about 3-4 months maybe longer and it immediately made me think it as him being a google maps disciple /o. No smooth flow, just boxcar driving, so there you have me opinion. Plastered a few hundred of these on the motor/express ways junctions and service stations and on the go did not get the turn:lanes / connectivity right… when a lane ends there’s no slight_left, there’s a merge to left, so spend quite a few hours to fix those.

I doubt these were random edits, trying to mess things up. These appear to be well-intentioned edits that appear to be accurate, and in line with how intersections are generally modelled.

Please don’t denigrate people by saying their work looks like the scribbles of a one year old. Even if they weren’t accurate, this is not how you should respond to it.

3 Likes

Say, can someone clarify what was meant by “dogleg” in the title of this topic? I guess it means something different than in American English, where it refers to a staggered side street:

Apart from that, the Waze community coined “micro dogleg” to refer to a specific hack of introducing a minuscule jog to the left or right to force the router to say left or right at a fork in the road. But Waze’s digitization practices differ significantly from OSM’s, so I wouldn’t look to that as precedent, good or bad.

I see some abrupt angles in the ways at this intersection, but it appears to be motivated by the physical separation principle rather than optimizing guidance instructions. It should be fine, since the major routing engines don’t take the turning angle so literally at the immediate intersection node; they instead look past the intersection by some distance to classify the maneuver more holistically. (It was Waze’s inability to do this that led their mappers to come up with the MDL hack in the first place.)

1 Like

The only issue I see that could impact routing in this changeset is the use of highway=primary_link instead of highway=primary for one way that isn’t a link but is part of the main road, and a couple of incorrectly tagged (both not needed and not valid) junction=yes nodes. I’ve corrected these in 148405656.

For 148325203 I’ve dropped way/1198636768 down to highway=primary_link to match the other side of the intersection since it is actually a link. Fixed in 148405707.

For the third changeset I can’t see any issues that would cause problems, it’s just an intersection that doesn’t translate as well when it’s as detailed as OSM gets.

9 posts were merged into an existing topic: Junction Nodes (Split from dogleg thread)

4 posts were split to a new topic: Junction Nodes (Split from dogleg thread)

Maybe hockey-stick speaks more to you. So it is a Waze/Google thing, who’d have thunk.