Australia’s idea and America’s idea of classification both differ from OSM’s idea, which is trying to have the same classification system globally. Trying to force Australian rules over actually bothering to conflate data into OSM rules is clownshoes thinking.

I think you’re the only one in disagreement on how this is mapped.

I’ve re-added the note contents at https://www.openstreetmap.org/note/2060067 , but I suspect that it’s really a more general question (“how should we tag the destinations of individual lanes”). The answer to that is that there seems to be some usage of “destination:lanes” - see https://taginfo.openstreetmap.org/keys/destination:lanes#overview for the number in use around the world and https://www.openstreetmap.org/way/375327794 for an example on the I5 South not far from you. What I don’t know is whether a Tesla will actually use that information (https://wiki.openstreetmap.org/wiki/Key:destination#destination:lanes.3D.2A_tagging asks that question more generally). You’d have to ask Tesla that question.

I do apologize for my rather aggressive tone in the note, I’ve been under a considerable amount of stress and it’s been affecting, probably most pronounced, my performance with OpenStreetMap of late.

I’m not convinced Tesla is actually smart, given the number of times I’ve seen ‘em drive headlong into trees, concrete barriers and pedestrians with the driver overtrusting the driver assistance in my city. Plus the hype surrounding electric vehicles and driver assistance technology overselling the benefits is creating a parasitic drag in many cities on adopting actually city-scalable infrastructure and highway safety in the urban context. I’d probably take a lot less dour view of the company and it’s products if they were honest about their product: “Look, it’s basically an GM EV1 with Cadillac’s supercruise and a higher price tag, and it’s never going to be as good as a sober and alert human driver except under ideal rural highway conditions.” They’ve chosen the opposite tack, thus Tesla considered harmful.

But more to the subject of the map itself, the way I’ve seen most data consumers actually work is to ignore destination:lanes and infer the destination from the destination= tags on the ramps, essentially using the turn:lanes=* tags to imply destination:lanes=* based off the destination. I think mkgmap does this, Magic Earth does this, Osmand does this. This is probably the better way forward from a human prospective, destination=, junction:ref=, destination:street=* destination:ref=, and the destination::to=* tags are all trivially straightforward. JOSM has a good turn lanes editor. Slap :forward or :backward to thee end if need be for two-way traffic flows. You could have some seriously Cities Skylines level absurdity with toll plazas in multilane cloverleaf lane drop split interchanges before you run into the risk of overrunning the size limit on values.

destination:lanes=* not so much. destination:lanes=* very rapidly runs into the problem of overflow. The 255 character value limit means destination:lanes=* can easily overrun the length limit where lanes have multiple destinations and there’s three or four lanes, with most of the information being redundant and long. It’s also way less effort to just remove destination:lanes=* when doing lane tagging than to update the values, even with an advanced editor.

I really wish id drew lanes and had an easy lane editor like JOSM does, however, as the lack of this functionality does tend to cause lane tagging to break with subtlety and silently without obvious feedback that this has happened

I think there’s a long stretch between the ignorant and minor scale bumbling of a new or student mapper that doesn’t have a proper grip on what they’re doing, and a corporation doing the same thing at a large scale, then running someone to an OSMF position.

No offense to migurski on this, and his extensive previous work with considerably better behaved corporate entities with interests in OSM. I have a hard time believing that he wouldn’t become a proxy for FB, to the detriment of OSM’s interests and his own personal interests. Especially fresh on the heels of the GlobalLogic debacle and FB’s involvement in severely and possibly irreparably harming humanitarian and political processes in entire sovereign countries.

@Kevin_Bullock: Really just sliding around Tulsa or along the length of US 412, US 169 or US 75 in Oklahoma, you can see it wobble substantially. I think I was looking up northwest of Cashion, OK when I saw it go totally off the rails.

Can we get some better alignment and resolution on the latest Maxar imagery? Not only is it not lined up, but the way that it’s out of alignment varies quite wildly over distances as short as 100m, and at resolutions that make it impossible to make out lanes.

Nice catch, Carnildo. “Speed limit” isn’t even the correct verbiage for those yellow signs, they’re Advisory Speeds in the US and Canada, and don’t have the force of law, just guidance of what the DOT can send a sedan around without passengers feeling uncomfortable.

So, I got a Waylens Horizon, now how do I use it for OSC?

It’s actually a government corporation and it doesn’t get much money from the city (a recent year actually had its budget set at $0, because Republican austerity) and basically stays open due to grants from USDOT and George Kaiser. But open in the loosest sense of the word, last bus is somewhere between 4:30 and 6:00 for most routes and the buses only come once every 45 minutes at best, the nightlines don’t start until 7 and don’t run past midnight.

I defy you to work out the Suburban Acres bus route in Tulsa Transit… I’m pretty good at working with relations and that route with it’s six variations is a real headache.

I wouldn’t map transitions quite like how you have mapped there. I’d put the junction at the tip of the theoretical gore and the end of the transition at the physical bullnose.

Not on Twitter, but I did the equivalent on G+. https://plus.google.com/+PaulJohnsonTulsa/posts/1YtDPqM3CEv

I’m looking forward to this going into the Improve OSM plugin.

Well, it’s not always not noticeable. Washington and Texas have very, very long exit lanes, sometimes the entire distance between ramps that might be miles apart (Washington for example, expects you to signal your turn the entire time you’re in the turn lane and has reminder signs to this effect…especially annoying when the turn lane is ~7500 meters long!). Washington and Oregon also have noticeably shallower, longer gores compared to most other states ramps as well, option 2 gives a prompt so early on Garmins and Osmand that you’re not even to the theoretical gore before the announcement to turn at the top of the ramp starts and you might be at or past the decision point for the next ramp by the time the first prompt after entering the freeway plays. Plus option 2 gets plain hard to deal with if the freeway is also on a curve.

This is less prone to be an issue with my preferred method, but does occasionally come up on comically huge gores built up from decades of interchange revisions, a relatively rare trade.

How about a fourth contender.

Imagery is Bing, location is https://www.openstreetmap.org/way/180337791

I think the objects are clear enough in the shot pretty self explanatory as outlined. The placement=transition highlighted is joining the highway=motorway_junction node placed on the inner westbound carriageway centerline longitudinally even to the theoretical gore point, and goes as smoothly as possible to the centerline of the exit ramp, longitudinally even with the physical gore.

This also (fairly) neatly handles starts and ends of medians as well, the “transition” segments start at the physical gore (end of the median) and continue to the theoretical gore (pavement markings). Where a both_directions lane is present, then it goes from the end of the double solid lines on both sides to the bullnose.

I’m also a fan of Osmand.

US 6 between spanish fork and I 70 being trunk is leftover NE2 vandalism, from when he bulk-retagged all US routes that weren’t motorways as trunk regardless; and the history on a random sample of segments confirms this. I’d generally consider that a primary; the tiger import got it right on this.

UT 154… I’m not seeing a reason any part of that should be motorway. Seems pretty clearly a trunk through and through. It might later become a motorway if the at-grade intersections intermediate and at the south end is eliminated.

US 89, agreed, that’s definitely a trunk between Farmington and I 84. North of I 84, looks like it turns primary and is yet another example of NE2 smash-tagging everything with US in the ref as trunk.

Looking at that example screenshot, kind of leads more support to my theory that it’s time we start tagging for where the parking strip and bicycle lanes are on the street in order to provide correct lane guidance.

In general I change the centre_turn_lane=* or center_turn_lane=* tagging to the more widely used turn:lanes tag.

I’d argue that using ref=* on highways to describe road routes was a big mistake in the first place and a legacy of not having relations. This further complicates things in that Oregon has separate highway numbers and route numbers that don’t usually match up; the highway number belongs to the road, not the route; and the route number might cross several different highways.