[Tagging] I can't support transit:lanes

osm.tagging at thorsten.engler.id.au osm.tagging at thorsten.engler.id.au
Mon Jun 11 11:39:29 UTC 2018


From: Jo <winfixit at gmail.com> 
Sent: Monday, 11 June 2018 17:47
To: Tag discussion, strategy and related tools <tagging at openstreetmap.org>
Subject: Re: [Tagging] I can't support transit:lanes

 

Name should indeed be changed, but I'd go for lanes:transition...., so it groups with the other lanes related tags. Not sure if that is a good type for the relation though.

 

 

 

Two issues here.

 

First, the tag is not “transit:lanes” the tag is “transit” and it can be used with the generalized “:lanes” suffix. 

 

There are general rules for the :lanes suffix which can be added to pretty much any tag you would have on a highway were the value could be different for different lanes. See https://wiki.openstreetmap.org/wiki/Lanes

 

It’s the same with e.g. “turn:lanes” (a “turn” key with the “:lanes” suffix) or “access:lanes” (a “access” key with the “:lanes” suffix).

 

So changing it to lanes:whatever would totally change the semantics of the key.

 

Second, the “transition” tag is already in use: https://taginfo.openstreetmap.org/keys/transition

 

Now, as far as I can tell, these are pretty much all transition=yes tags on power=tower or power=pole nodes. These seem to be left-overs from a previous tagging scheme, which has been replaced by the use of the location:transition=yes tag (and at 342 vs 13388 uses that seems to have been well accepted by now).

 

So I guess it might be possible to coordinated with people that are involved in power mapping to have these remaining ones retagged to free up the transition key.

 

The type=transition value is currently unused, so in that regard the change would be fine.

 

 

From: Simon Poole <simon at poole.ch> 
Sent: Monday, 11 June 2018 18:43
To: tagging at openstreetmap.org
Subject: Re: [Tagging] I can't support transit:lanes

 

Just as Bryan does, I can see supporting special casing transit relations (as we already have to do the same for turn restrictions). I am -very

 

 

The transit:lanes proposal goes into a lot of details about why it can be tagged on both relations and ways, and I’m not going to repeat all that. 

 

It boils down to that tagging it on a way is much simpler for the mapper (for cases where the from and to ways are unambiguous from context). With current tools, creating a type=transit relation manually is at least an order of magnitude more work than just tagging it on the way.

 

IF transit(ion) relations would have first class editor support, at the level of the turn restriction editor in iD. Then I would see no need for keeping support for transit:lanes on ways. 

 

 

 

From: Bryan Housel <bhousel at gmail.com> 
Sent: Monday, 11 June 2018 14:42
To: osm-tagging <tagging at openstreetmap.org>
Subject: [Tagging] I can't support transit:lanes

 

I’ve had a few recent conversations about this proposal:

 https://wiki.openstreetmap.org/wiki/Proposed_features/transit

 

Unfortunately I can’t support it.

 

Not only is the name bad (it should be named `transition:lanes` but whatever), the bigger problem is that, as proposed, the tag can be placed on either a way or a relation.

 

 

See above for feedback on both these points.

 

 

 

The problem with tagging these on ways is that if you split the way, the tag breaks.  

 

No other tag works this way (except maybe for address interpolation lines, but presumably anybody splitting one of those would know that they need to adjust the numbers on the endpoints).  

 

I’m not going to add a special rule in iD to warn people if they are splitting a way with a lane transition tag.  I don’t want to speak for the JOSM devs, but I doubt they would implement something like this either.

 

 

 

I agree that this tag when used on ways is problematic from an editor perspective. 

 

Though by following pretty simple rules, the editor could prevent the transit(ion):lanes tag on a way from breaking:

 

https://pastebin.com/BGWvp6QU

 

IF there is proper first class editor support for creating/maintaining transit(ion) information, then there would be no need to allowing to tag it on ways directly.

 

 

The only way I’ll be able to support lane transitions would be as a relation that has similar semantics to turn restrictions.. from/via/to.  Keep it simple (no multi via ways please).  This is already an understood way of tagging things that connect 2 ways.  (could you imagine if we tagged turn restrictions as  maybe-a-relation or maybe-a-way-tag ?? nope!)

 

 

Transit relations have no via, and they don’t need a via. The from and to way should always touch at exactly one node. Otherwise they are invalid. So you can always determine the “implicit” via node from that.

 

Other then that, yes, they should be treated pretty much like turn restriction relations.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20180611/c895ae02/attachment-0001.html>


More information about the Tagging mailing list