Proposal talk:Placement

Please add to the discussion using the Add Topic button above. Keep discussions succinct, try to stay on topic, and mark finished conversations with {{Resolved}} and related templates.

Motorway exit change

I think that the proposed change for the first independent node (the second node of the motorway_link) for exits is misthought. IMHO it even fails to help what one tries to achieve with this proposal because the first segment is not even inside the road geometry (area) anymore! - Ij 16:07, 20 December 2012 (UTC)

Please read again. This proposal does not change anything. It simply provides a new information. --Imagic 16:38, 20 December 2012 (UTC)

Please check images in "Current status: motorway exit" vs those in "Motorway exit". If true and nothing is changed, please fix images then as they are very confusing and clearly show the _link way going through area where there's no road! -- Ij 18:28, 20 December 2012 (UTC)

Compare the two images in "Motorway exit". Same problem - two completely different mapping styles. And that is exactly what I want to show. No matter what style you prefer: tagging with placement provides enough information to get a more accurate outline of the road and course of the lanes. That's why I use different mapping styles in the examples. --Imagic 09:17, 21 December 2012 (UTC)

Ok. I see your point and agree that it's possible to infer the geometry like you suggest in that case too. However, as is it doesn't show the equal one at all, it obviously leads the reader to think that this "change" is part of the proposal. Also, I still think it's somewhat unwise to endorse that particular node placement scheme in the first place as with it highways end up going outside of actual, physical road area (and this proposal page does it not only once but twice!). --Ij 22:50, 21 December 2012 (UTC)

Right now this proposal is only a draft. I will add some overview at the beginning and explain in short words what this proposal is about and what it is not. --Imagic 08:12, 2 January 2013 (UTC)

Btw, after some more thinking, I don't even know how I'd be supposed to tag placement=* if using the "current status" node placement approach. Therefore I think an example would be very helpful. I.e., how the renderer would know how long the diverging ways are connected (and which ways? as the non-link way could be split during that time already due to some other reason). --Ij 22:50, 21 December 2012 (UTC)

If you fork the OSM-way at a point where the road does not fork, no sensible tagging scheme on earth could help you. You would need to put the ways you just separated into one relation to tell the consumers that the separate ways are in reality just one. That's one - or two - more splits and one additional relation just because the node is not where the road forks. That's much too complicated for me. Please wait until I made some examples based on aerial images. Hopefully you are happier with them. --Imagic 08:12, 2 January 2013 (UTC)

Like this: "Current status: motorway exit" ???

Yet you say "not change anything"?!? ...I don't follow.

So the cost of this proposal is now "breaking" vector based map completely as the _link road vector is guaranteed to overlap with a non-travelsable road part (either solid line or entirely outside of tarmac)? I mean like this:

or

...If you don't believe me it breaks, now imagine that we have two residential streets. One is straight and the other ends to middle of it with 45 degrees angle (how much angled they are is irrelevant here). Clearly there's a fork drawn into osm where the "road does "not" fork" by the same definition you're using here. And such non-fork is why the road vector does not end up departing the designated road area and cut through somebody's property. I don't think it's any better from vector based map point-of-view to have such cut-throughs occuring with links, i.e., to draw highway where it's illegal/dangerous to drive.

I understand the need for the placement tag and I'm very supportive in general for such. However, I'd like to see that it keeps both entirely vector based and entirely placement based maps sensible. Perhaps some placement=joint_left would solve most of the cases easily enough (but then splits in the main motorway require something more tricky I agree, I now understand much better why there were those triangle ways posted to @tagging some time back). -- Ij 19:34, 12 January 2013 (UTC)

Tag Name

Have seen the placement tag today for the first time and had no idea what the tag is meant for. I would suggest to change the tag name to road:placement or lane:placement or something like that to indicate what the tag refers and be more descriptive. Also, we may need a [xxx:]placement tag for other things in future so it would be easier to see the difference SunCobalt 08:85, 10 February 2013 (UTC)

I'm afraid it's a little bit late now as it is used over 10,000 times already according to taginfo. That's a lot for such a special-purpose tag. --Imagic (talk) 08:45, 10 February 2014 (UTC)

I would also like to see it as lane:placement. Changing it is still possible as long as it is only "proposed". Better to change the 10k tags than to have tag collisions in the future (like label placement, lamp placement, ...) and to avoid confusion. --Michael Z. (talk) 13:52, 25 November 2014 (UTC)

It is de-facto approved as it is in use about 24000 times as of today. OSM works this way. It does not work by voting or approving by ten or twenty people. --Imagic (talk) 08:04, 1 December 2014 (UTC)

Avoid splitting of ways

In order to avoid splitting of OSM ways due to placement=transition Proposed features/Suffix start and end can be used:

No placement tag necessary. Merged with way of section 3 placement:start=transition Merged with way of section 5 up/down: placement:start=transition

No placement tag necessary. Merged with way of section 3 placement=right_of:1, placement:start=transition Merged with ways of section 5 down only: placement:start=transition

--Slhh (talk) 01:28, 9 February 2015 (UTC)

Definition of value transition is inconsistent

Value	Description	Example
transition	The OSM-way is neither in the middle of the whole road nor does it run parallel to some lane. This value should be avoided whenever possible and is usually only necessary if the road forks or joins with another one.	placement=transition

This definition doesn't fit to the examples:

No placement tag necessary. placement=transition No placement tag necessary.

In the example above the osm way is always in the middle of the whole road. According to definition it must not have Tag placement=transition. This isn't really a placement transition but some tagging is required to specify lane transition. Tagging section 2 with placement:start=middle_of:2, placement:end=left_of:2 would help in this special case, but this method is limited to a oneway. Therefore we need some other method for the lane transition. The same applies to section 1 to 3 of the following example:

No placement tag necessary. placement=transition No placement tag necessary. up/down: placement=transition No placement tag necessary.

Using a different mapping style the placement of section 2 is parallel to a lane:

No placement tag necessary. placement=transition placement=right_of:1 down only: placement=transition No placement tag necessary.

In this example section 2 still must not have Tag placement=transition according to definition.

--Slhh (talk) 01:28, 9 February 2015 (UTC)

Good point. Examples are correct, but the definition is bad. I'll try to improve the wording. Thanks! --Imagic (talk) 07:56, 9 February 2015 (UTC)

I'm not sure how the new definition "The OSM-way is does not run parallel to all lanes in the middle of the whole road." should be understood, but I believe its wrong anyway.

Assuming the scope of "not" includes the term "in the middle of the whole road" a unidirectional road with "placement=left_of:1" falls into the definition of "placement=transition", because the OSM-way is not in the middle of the road.

Assuming the scope of "not" does not include the term "in the middle of the whole road" section 4 of the motorway_exit example must not be tagged with "placement=transition", because the OSM-way is not in the middle of the road.

I see some valid idea behind "placement=transition", but i believe difficulty to define is indicating that this tag isn't technically mature. The tag has likely been intended for too many incompatible applications.--Slhh (talk) 01:43, 6 March 2015 (UTC)

Left-hand traffic

How to number lanes in case of left-hand traffic? In case of numbering from left to right some frequently used tags for right hand traffic like placement=right_of:1 or placement:forward=left_of:1 have to be replaced for left-hand traffic by some tags more frequently changing along the route and therefore being more error-prone.

Add some syntax to number from right to left optionally? Example with lanes=4: middle_of:R2 or middle_of:-2 could be an equivalent to middle_of:3 --Slhh (talk) 00:54, 10 February 2015 (UTC)

No, that would be much too error-prone. Lanes are always numbered from left to right, no matter what kind of traffic. Keep it simple. --Imagic (talk) 08:04, 10 February 2015 (UTC)

Reversing an OSM-way in the Editor

Reversing an OSM-way in the editor should not damage anything. Concerning a motorway this isn't likely a significant issue, but in the city this might be a real problem. What does the editor have to do in this case? --Slhh (talk) 00:53, 10 February 2015 (UTC)

On two-way roads one usually uses placement:forward resp. placement:backward, which is adjusted automatically when reversing the OSM-way by JOSM. I don't know about other editors, but at least the major ones should support exchanging :forward and :backward, as far as I know. --Imagic (talk) 08:03, 10 February 2015 (UTC)

Additional values

Some additional values are likely useful:

Intended Fuction	Possible Tag
The OSM-way is placed in the middle of the width of the whole road (OSM way). At least for oneways this is the default for historical reasons.	placement=middle_of:width
The OSM-way is placed on the separation between forward and backward direction of the road. This might be considered the default for bidirectional roads.	placement=separation or placement=directions or placement=center
The OSM-way is placed on right side of the whole road (OSM way).	placement=right
The OSM-way is placed on left side of the whole road (OSM way).	placement=left

--Slhh (talk) 01:39, 10 February 2015 (UTC)

Most of these can be represented with the current values, maybe except middle_of:width if lanes have differing widths. I would keep the number of values to a minimum. --Imagic (talk) 08:00, 10 February 2015 (UTC)

I would definitely like placement=separation. In many situations it makes the most sense. Mar4s (talk) 22:21, 27 February 2015 (UTC)

I had a look at taginfo and the value left_of:1 is the most used value for placement:backward and placement:forward. Assuming that most placement-tagging is done in countries with right-hand traffic, this value is equivalent to "separation". So it would make sense. On the other hand the value might only make sense if it could be used as some kind of shortcut and the mapper has to enter the value manually, because if we assume that we have some kind of presets it doesn't matter what the actual value is. But the value "separation" is longer than "left_of:1" and it is an additional value the mapper has to remind. So I don't see any advantage of "separation". --Imagic (talk) 15:18, 4 March 2015 (UTC)

The value 'separation' is easier to type especially with one hand (other hand on mouse) because it doesn't use special characters. Using 'separation' forward/backward can be omitted. Therefore the full tag is even shorter and can be totally omited in most cases, because it can be easily defined as default for bidirectional ways. Value "left_of:1" would be a very bad default especially in view of left-hand traffic.

Using 'placement:forward=left_of:1' for bidirectional roads is a dirty workaround, because the Tag is intended to place the full road including the backward direction part. A 'forward' key should impact forward direction of the road only. In addition the left-hand traffic equivalent of the workaround is much more complicated.--Slhh (talk) 00:20, 6 March 2015 (UTC)

For me "separation" is better, because it's easy to write and has intuitive meaning. I don't like to use presets too much, because adding tags manually gives you better control over outcome. And it's direction non-dependent (left- and right-hand), that's a nice bonus. Mar4s (talk) 10:27, 7 March 2015 (UTC)

90 degree bends

Before it was more obvious on how to connect exit lanes to highways. But with the placement tags, we get 2 90° corners on those highway exits in some cases. How should those be handled? Especially for software that don't support placement.