@mvexel: This is where placement=* comes into play. Osmand generally assumes you will end up in the corresponding lanes once you get around the corner, which from my experience is a reasonably safe assumption (and follows either best practice or the law everywhere to the best of my knowledge).

This does mean that you sometimes have to work out the centerline of through lanes for miles at a time, something in my quick and dirty example I only did to a logical stopping point. And sometimes, switching the centerline location because, say, a new lane joins on the right, then miles later a lane gets dropped on the left. I usually make such a transition at the drop if possible, tagging which lane ends, with the end of the lane line starting a new segment with one fewer lanes, placement=transition. I also use a placement=transition for situations where one or more sides of a link face a flush median like a theoretical gore, and have the junction node even with the point that theoretical gore’s nose, ending at the ramp’s centerline start adjacent to the bullnose.

OK, I’ve taken a crack at it. You’ll probably need to use JOSM with a lane-aware rendering style. Osmand should give proper lane-level guidance on this intersection now.

What’s the location? I can take a crack at this. I’ve had experience mapping a pretty big variety of intersections now as I try to lane-map every state highway in Oklahoma.

I, too, am missing what is wrong with this picture, and I’ve been to the area in question.

Be sure to include placement as well. Such as in the above example, placement=middle_of:3

If you really want to go insane, try mapping routes that have a lot of ways that appear more than one time in the same relation…and accidentally sort it

Heh, I don’t even have to zoom in to know that’s the McAlester Army Ammunition Depot.

On the blue motorway_link could also take on the following tags:

junction:ref=33 destination=Halfmoon Bay;San Mateo;Hayward destination:ref=CA 92

I’m still of the opinion that ref=* on the highway=motorway_junction isn’t cutting the mustard.

1. While exit numbers are required in interstates, they’re not yet widely rolled out on any other American network. And even then, some states have opted to stop signing an interstate rather than go back through and (re)number the exits. California debated this with Interstate 5 for it’s nearly thousand-mile portion; Oklahoma stopped signing I 444.

2. What side is the exit on? junction:ref=* and destination::=* nails this fantastically on the departure segment of the exit, and what I’ve been focusing on when I map motorways in Oklahoma that have exit numbers. Oklahoma’s a relatively straightforward example, since only a dozen exits aren’t to the right, statewide. But I’ve tried mapping places with more complex edge cases: What happens when you have center exits? What happens when you have an even number of lanes, and lanes 1, 2 and 4 go through, but lane 3 is an exit? Where’s it go? What’s it signed as being an option to get to? What if it’s an exit when the motorway is going one way and an entrance when it’s going the other? The node tagging just doesn’t capture this except in the most ham-fisted possible way.

3. Node tagging for this already lost. Data consumers aren’t consuming motorway_junction because it’s ambiguous for the first two reasons. But at a minimum, osmand announces destination=* and destination:ref=* along with the direction of the turn:lanes=* or turn:lanes:= direction for the most likely lane.

OK, in Portland terms, and I know these are all mapped out locations… I tend to think of railway halts as minor in-line stations, like Beaverton Creek, East 162nd Avenue, and Fair Complex/Hillsboro Airport. I consider them stations if they’re a bit larger and intended as a junction point between lines, such as Hillsboro Central Transit Center, Beaverton Transit Center, Gateway Transit Center, Portland Airport, Portland Union Station…

What do the numbers presented on the detected turn restrictions mean?

Damn…already knew them…

Heh, please share your experience with the mailing lists. I’m trying to get route=road to stick and one of the biggest arguments is that relations are a pain in id.

Destination definitely has the advantage of being applicable to more situations than just freeway exits, being more specific (a real issue given about 20-30% of ramps in my region are something other than off to the right, and I’m aware of some truly convoluted ramps that barely grasp real world logic much less are something that can be readily assumed by data consumers from a single point), and already has live adoption (Osmand at the very least).

You should bring the changesets to the attention of the DWG

@robert: If id is unable to handle relations in a rational manner, given that relations are a basic data type alongside ways and nodes, that’s a major deficiency in id and should be pointed out to the devs.

@Sanderd17: That’s not true at all, or the cycleway and walking networks would have the same refs as the motoring network. It took me all of 15 seconds and zero effort just zooming in on a random location and finding a duplexed ref (in this case, road A27 and RCN CS7 in London).

I’d throw junction:ref on the same way as the destination=* tag. I realize in theory it’s rare to need that level of disambiguation but in practice, there’s enough mutually split (such as the end of a long ramp where a “C,D,E” of a multi-ramp exit split), left, or some central lane (still can’t believe Oregon actually made lanes 1,2 and 4 the through lanes, and lane 3 an exit only lane where OR 8 splits from US 26 westbound; that one being the weirdest of the “not leftmost/rightmost-lane exit” situations I’ve seen).

Especially since many of these routes are already multiplexed with the only difference being the mode of travel.

So what makes motorists somehow privileged as a mode to do it differently than we already handle foot, bus, bicycle, and literally every other kind of route?