From: Paul Johnson <ba...@ursamundi.org> Sent: Thursday, 14 June 2018 08:00 To: Tag discussion, strategy and related tools <tagging@openstreetmap.org> Subject: Re: [Tagging] I can't support transit:lanes
So how is this different from placement=transition, then? placement=* defines the relation between the position of the way that defines that is used to specify the position of the road to the lanes. Without a placement tag, the assumption is always that the way is in the exact centre the total width of all lanes. with values like left_of:1, right_of:2, middle_of:3 you can specify that the way is at the left, right, or middle of a specific lane (lanes always counted from left to right, and matching the lanes defined in the :lanes suffix tags, not the lanes=x “full-width motorized” lanes. You can see the effect of that in this screenshot from JOSM with the “lane and road attributes” mapstyle active: https://www.dropbox.com/s/f18xbtvdcjg8syo/1520437709804.jpg?dl=0 https://www.dropbox.com/s/o5mgkj7bdmwe6rx/1523175198420.jpg?dl=0 Where possible, I’ve simply kept the ways following a specific on the ground lane, even when lanes are added and removed, by using that appropriate placement=* values. Otherwise, to be absolutely correct, the way would have had to wiggle left and right every time a lane is added or removed for a short section to keep the position of the way in the centre of the total width of all lanes. placement=transition indicates that the way is not actually in a fixed position to the lanes for this segment. This is required at places where ways split or merge because we are using lines (the ways) to define the position of areas (the actual road surface). For a concrete example, see (from the 2nd screenshot, motorway_link coming up in the bottom right corner): https://www.openstreetmap.org/way/577734615 At that point, it has 4 lanes, these lanes split into two 2 lane ways. For the short section where the split takes place, it’s impossible to define a correct placement value, as the way for the 4 lane section is in the middle of the 4 lanes, while the way for the later 2 lane sections is also in the middle of each. So for the two small sections where the way is not actually correctly positioned, you specify placement=transition, to basically tell the data consumer “you’ll have to figure this out based on how the lanes connect”: https://www.openstreetmap.org/way/577672034 https://www.openstreetmap.org/way/577672029 transit:lanes on the other hand defines how the lanes connect from one way to another. While this information can, partially, in some cases, with some guessing, be derived by analysing the placement, and :lanes tags, it’s much easier if the information is directly defined. It essential defines “if you are currently in a specific lane of way A and you go from way A to way B, what lane of way B will you be on without having to change lanes (crossing a lane dividing road marking)”. Cases where it’s definitely impossible to determine that from placement and other :lanes tags is the difference between a new lane being added (so you have to change lanes to get into it) and a lane forking (the lane gets wide enough to be two lanes, then a new dividing line is starting in the middle, you can essentially arrive at either of the two new lanes without changing lanes). As well as the same in reverse, a lane merging (the lane ends, you have to cross a dividing line to get out of it) or two lanes joining (the lane dividing road marking simply stops, going from two lanes to one double width lane, which then shrinks to normal lane width, in which case from both original lanes you will end up in the new lane without crossing a lane divider). Take for a simple general example this way (also from the 2nd screenshot): https://www.openstreetmap.org/way/577734617 A motorway_link splits off: https://www.openstreetmap.org/way/577671984 while the way itself continues: https://www.openstreetmap.org/way/577671983 The lane connectivity from that first way to the two splitting ways is defined in two transit relations: For the slipway: https://www.openstreetmap.org/relation/8189793 transit:lanes=continue|leave|leave because it’s a :lanes suffix key, the number of | separated values must match the number of lanes defined in the other :lanes keys on the from way. The value tells you that the left-most lane of the “from” way continues to the left-most (only in this case) lane of the to way. While the two lanes on the right do not connect to the “to” way at all (they go to some other way). And for the through road: https://www.openstreetmap.org/relation/8189792 transit:lanes=leave|continue|continue The value tells you that the left-most lane leaves to some other way, while the middle lane connects to the left-most lane of the “to” way and the right-most lane connects to the 2nd (and right-most) lane of the “to” way. Another example (the tag is defined on the way here, which, as we have established, gives the editor authors a hissy fit; the same information could be defined in a transit relation instead, it just takes a lot more work for the mapper to create in the absence of simply point and click editor support) (this is from the first screenshot): >From https://www.openstreetmap.org/way/578649804 to >https://www.openstreetmap.org/way/567520097 a new lane is added. As a >complicating factor, that lane is added in the middle of the existing lanes, >so it’s impossible to just line up the lane positions using the placement and >width:lanes keys to figure out which lane connects to which. (on the first way = “from” way): transit:lanes=continue|new_on_left|continue the “to” way is unambiguous because the from way is a one-way and only a single other way connects at the node where the traffic flows out of the from way. The transit tag indicates The following lane connectivity: (bike lane) -> continue -> (bike lane) --------------------------------- (new lane) (left vehicle lane) -> new_on_left -> (continued, now middle, vehicle lane) (right vehicle lane) -> continue -> (continued, still right, vehicle lane) As you can see, while there is some relation between the placement tag and the transit tag, they define very different things. Also, tagging on the way, while I agree that it is a problem for editors, when used correctly, is just as easy if not easier for data consumers to interpret than creating a relation for it. The exact same information could be tagged on a relation instead, the only reason for tagging it on the ways is that it’s much faster and easier for mappers to enter. You can also see, because transitions are defined to be always from the end of a way you don’t need an explicit via node in the relation, because the end node of the from way, which must be a shared node with the to way, always gives you your implicit via node. Cheers, Thorsten
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
