To address traffic flow relative the centerline: my understanding is that a driver offset some lane count from the centerline of a way should, when the way splits, maintain that offset relative to the outlets. Using the sample 2–1 Y-junction I mentioned in my first reply: a driver in lane 1 or 2 of the inlet should be in lane 1 or 2 of the major outlet, respectively. Similarly, a driver in lane 3 of the inlet should be in lane 1 of the minor outlet.

However, this offset should also consider lane positioning offset left, center, or right of the chosen lane (i.e., as defined by the placement tag). So if a driver is travelling along the left_of:2 line of the inlet should exit the split along the left_of:2 line of the major outlet. Similarly, a driver along the right_of:3 line should exit the split along the right_of:1 line of the minor outlet. Avoiding transition ways would allow routers to use this heuristic; using transition ways introduces intractable ambiguity.

Commercial maps appear to prioritze road curvature over centering as well. However, they choose a centerline for the inlet way that, if copied into OSM, introduces avoidable placement=transition ways.

[Google Maps][1] selects the left outlet from the split as the bypass, branching off with what we’d consider a transition way. The right outlet maintains the centerline from the inlet. However, they mangle the centerline at the merge point upstream, shifting it one lane leftwards. An OSM equivalent would have 3 transition ways: 1 for the minor outlet at the split, and 2 for the inlets at the merge point.

[Bing Maps][2] does an arguably worse job: the decision point has been unnecessarily pushed back, and the centerline transitions from the middle lane of the inlet to the right lane of the major outlet. However, it still prioritizes curvature: the left outlet is the bypass again and branches the same, but at a slighter angle than GMaps. At the merge, it preserves the curvature of the major inlet: the bypass merges with another branch. The lane placement transitions from the right lane of the major inlet back to the middle lane of the outlet. This configuration in OSM is objectively worse: it requires about 5 or so transition ways(?).[^3]

The current configuration in OSM is (probably) optimal for avoiding transition ways. I’m not sure if there’s some other selection of centerline for the inlet way at the split that would yield better results.

[1]: https://www.google.com/maps/@33.0639548,-96.6905261,205m/
[2]: https://www.bing.com/maps?cp=33.063694%7E-96.690596&lvl=19.1&style=h
[3]: Eyeballing it, though it probably more.

I think there’s a compromise between mapping to a perceived centerline from aerial imagery/traces and a virtual centerline that produces a useful abstraction. Blindly gluing the way to the perceived centerline would give results like [this][1], introducing unnecessary curvature where IRL there is none. If I had just corrected the placement tags, the geometry here would still contain at least 4 unnecessary deviations—4 instances where I would have to partition transition ways—from actual road curvature at the junction and merge points that suggest to a data consumer an unpredictably different reality to what’s present. In this case, this is avoidable by placing the split and merge as I have; in most cases, this is not, esp. with highway ramps as you’ve mentioned.

Since OSM is necessarily a simplification of reality, I would expect compromises between this abstraction of reality and reality itself. Ways are inherently imprecise: we’re still using 2D lines to represent the 3D carriage way area. Even if I wanted to, area:highway is dead: cursed to wander proposal purgatory for the better part of 10 years now, relegated to mere router set dressing. And areas are *still* second-class objects for some asinine reason. If OSM had a functional area routing model, we wouldn’t be having this discussion in the first place since a router would inherently deduce lane placement itself. POI locations are often both inaccurate and imprecise: sometimes the POI is the entire building its contained in, causing routers to blindly route to the ways closest to it—even if it happens to be some back alley or loading dock. Sometimes the POI is just a point placed at the mapper’s discretion: would that point be actual location? Is it the center of the entire space the actual POI occupies? Something else? For these ambiguities, and whatever others I’ve not mentioned, I would prioritze predictability and useability over precise location.

Even so, data consumers must account for all these inherent ambiguities of the OSM abstraction. For ways, as I previously wrote, this includes

- ingesting the placement tag to correctly render ways;[^3] and
- resolving the mismatch between the user GPS and the virtual way’s positions, typically with some route recaculation threshold.

Also, in the [table][2] enumerating values for placement, the field for transition states that: “This value should be avoided whenever possible and is usually only necessary if the road forks or joins with another one.” I don’t see any other way of interpreting this other than avoiding tracing ways with the tag.

[1]: osm.wiki/Proposal:Placement#Motorway_exit_2
[2]: osm.wiki/Proposal:Placement#Tagging
[3]: Though there is still no widespread support for rendering with it…

I mean, I’m about as baffled as you are if destination tags should sync to turn lane tags—if at all. A common edge case I see with that is when there’s an off-ramp with more than one destination indicated and a through;slight_/left|right/ on the approach: how are the destinations separated aligned to the turn directions? A common idiom I’ve seen is to insert none to match the through indication, but then how to denote that the two destinations are a part of the turn? Most of the time, they’re appended as-is and it seems the assumption is that routers will set aside some code path to handle this fragile edge case.

IDK, all I know is that the wiki’s tentatively recommends just tagging destination/destination:lanes on the ways immediately before or after the decision point/junction. Since the wiki is the de facto standard, I’m assuming major routers account for this and diverge on anything else. Testing with OsmAnd at the very least shows this.

Also, apologies for the passive-aggressiveness: it was a bad night for me. I mean no ill-will.

I’ve replied to the affected changesets. Sorry about the passive-aggressiveness: it was a particularly aggravating night for other reasons, and I let that bleed over here.

I’ve explained my thought process about how these ways are placed at this [changeset](changeset/179212994#c1562475). I’ll reiterate that, in general, I have two goals:

1. preserve the road curvature with respect to GPS traces; and
2. avoid or minimize ways with placement=transition .

For the on-ramps leading to the junction, I aligned the ways to the right shoulder to minimize the transition way. This also gives me a defined line to trace the way without resorting to strange JOSM hacks. Thus, their position is still following parallel to GPS traces within a margin of error, and the curvature is (hopefully) improved. Renderers can correct for the centerline by ingesting the lane placement and lane widths. Routers already have adjustable margins of error for determining positions on-way.

The kinks you mention from the service roads to the on-ramps are a compromise between minimizing the transition way and keeping lane details. Ideally, I would follow the ramp’s shoulder marking to the junction point and extrude the end to meet the service road, but then the ramp would be unnecessarily long. In this case then, I chose to trace a way 30° about the service road to where the shoulder marking splits from the service road to the ramp. Major map services (I’ve checked GMaps, Bing) seem to also make this compromise.

The strange geometry at the on-ramp to US 75 N at Ozark Dr is an actual faff on my part. I’ll fix that.

That being said, I’m not familiar with editor consensus about this. If this has already been decided in some mailing list discussion and you happen to know, then I’m alright with just reverting this reversion.

I do consider these redundant, but this might be a more systemic issue from lack of clarification from the key:destination page on how far upstream destinations tags should be propagated from a sign or junction/merge point.

I used to place destination tags from first indication to junction/merge (as you’ve done), but I quickly ran into issues with destinations unserved by those intersections. What to do with something like a destination to `Mexico` at a Texas—Mexico border crossing? Would I just propogate the destination from the sign all the way to the border? Just to the next junction? Here, this ramp is short enough to not matter, but generally, the wiki doesn’t have clear answers to this. However, it does have recommendations on how to tag at junctions/merges/signs.

Interpreted as-is, the wiki recommends putting destinations on the outlet way immediately after the junction point and, if desired, putting lane-specific destinations on the inlet way immediately before the junction point. The wiki pages for the Series E MUTCD signs also recommend placing destinations on ways past the sign only when pull-through arrows are used.

Duplicating these tags is probably harmless to routing since major routers are capable of back-filling the per-lane destinations from a junction/merge point. With that, duplicating these tags along non-indicated ways seems to serve only as optional reassurances to editors that are difficult to maintain, especially for long stretches of road.

In my extremely unscientific routing tests with OsmAnd, I observed no difference in destination guidance with or without these tags. I’ve not yet tested changes with OSRM and Valhalla, but with their daily routing sync rates, I might start doing that.

My thoughts on this are, generally, that road curvature takes higher precedence than exactly matching the GPS trace. My understanding of the placement proposal, the goal of the key is to allow way geometries to do this. The proposal also recommends avoiding the `placement=transition` tag wherever possible.

When splitting from a Y-junction, I’ll aim to preserve the lane positions of a given car on outlet ways relative to the inlet way. For example, in a 3 lane cleanly splitting into a 2–1 split from offset `left_of:3` or `right_of:2`, a car in lane 2 of the outlet way exiting the junction to the major outlet should ideally stay in lane 2 of said outlet. In this example, I would use `right_of:2` and `left_of:1` on the left and right outlet ways, respectively. I apply this principle when merging Y-junctions.

I’ll also try to give precedence to the curvature of the perceived major outlet, if applicable.

To decide the general lane placement, I manually follow the road along aerial imagery against traffic flow to what I would consider an ideal origin: for example, on highways, this is typically when it becomes a 2 or 4 lane divided road. I then manually trace from that centerline to where I need a accurate lane placement. Sometimes this fails for a given origin and I have to choose a different one upstream; usually, this is at merge points on major throughfares.

In this scenario, with a 1–2 split with the given downstream placement, I made these assumptions:

1. from personal experience driving here and by signage: the left is the minor outlet (that bypasses to the US 75) and the right, the major outlet;
2. the placement of the inlet way (`left_of:2`) is dominant for significant mileage downstream; and
3. this placement allows for a clean split at the junction point without adding unnecessary `placement=transition` segments.

Considering all this, I decided to place these ways along their respective shoulders with the ideal lane placements. I placed the major right outlet first, then the minor left. Since the right way has curvature precendece, I avoided modifying its curvature when placing the left. I also checked to ensure that the ways were following parallel to OSM GPS traces within an eye-balled margin of error. As of writing, when I pull up traces and OSM data on the site, this is the case.

For the merge point upstream, I decided to maintain the lane placement downstream from the initial Y-junction.

A terminal case of me misinterpreting or not RTFM, apparently.

This is an update to surface data, *not* lane placements.

Source is Bing/extrap

Oopsie-woopsies.

I accidentally fat-fingered enter while cleaning my keyboard, hence the malformed source 😢

In my defense, I based my edit off the existing [wiki recommendation for route directionals](osm.wiki/Route_directions). AFAIK this style has been okayed by the community. I’m a bit confused about how I’m erring here when the example I used 1) has been approved and 2) does the exact thing that I’m doing.

If this is egregious enough, then by all means, do correct my mistake. If you’d rather I do it, then sure, I can abide that.

State Highway 6 South is quite literally the signed name used in my municipality; since that’s at best regional, I’ve excluded it from the route. On the other hand, AFAIK Highway 6 South is an incredibly common way to address the south-bound route, common enough that there are entire stretches of the route named after that. I would *really* like to avoid starting an edit war over something as silly as this.

Other variants include 3227 Hwy 6 and 3227 SH-6 N (at least that I’ve seen). I’ve defined the names with the context of the whole mass automated “name≠description” debacle that I was very specifically trying to avoid 🥲

These are the actual, in-use names in the region; for example, the address 3227 State Highway 6 South (street name given to stretches of both Highway 6 North and Highway 6 South) is commonly truncated to 3227 Highway 6 or 3227 Highway 6 North.
---

Published using OSMCha: https://osmcha.org/changesets/165747728

Source is actually the website, but I forgor change 💀

I forgor to add the rest of the comment: I adjusted the curvature of the links from US 59 Frontage Rd to First Colony Blvd and Sweetwater Blvd to US 59 Frontage Rd