Proposal:Subsidiaries

Subsidiaries
Proposal status:	Abandoned (inactive)
Proposed by:	*
Tagging:	Subsidiary=various
Statistics:
Rendered as:	Various

This proposal was formed on IRC, so bear with me.

This is meant to cover all objects along the sides of roads, such as laybys, passing places etc. This could also be used for canals' towpaths.

-- Bruce89 19:27, 16 April 2007 (BST)

• Still not completley shore how far to go with this, but some of the things that could go under a Subsidairies key would be: Layby; hardsholder/nohardsholder; buslanes; busstops; passing places; cyclelanes, pavements, towpaths etcetc. left_ right_ or something similar would need to be attached to each value (unless its ment to applie to both sides) in order to make them appear on the correct side of the way (relative to segment direction). Ben. 14:41, 26 April 2007 (BST)

• Yet I don't have an idea how this should look like. An easy example might be subsidary=layby. But what if there are other usefull things in between the single parking places, maybe parking places for cycles? Should it then be subsidary=layby,cycleparking or a lot of small ways? And what, if next to the road are laybys, then cycleparkings? This should be clarified in my oppinion.

I think, that this (and some other problems) come from the fact, that we look at roads as onedimensional objects, what is not really true. They do have a width, and if you attach all the things next to them to this object, the width increases.

Thus, in my oppinion it would be much better to have the possibility to attach a node/way/area to an other node/way/area. E.g. I'd modell a layby with two segments, one for the street, one for the layby and then I'd add a attachedto=<id of the street> to the layby. (The id should be derived by the editor and not by a human of course.) Below is an image of what I mean. --Kumakyoo 17:17, 7 May 2007 (BST)

ID numbers aren't visible to the user usually, so this would be hacky. Bruce89 18:48, 7 May 2007 (BST)

Yes of course. I added the id numbers only to show what I mean. In real life, this should be done by josm or what ever editor you use. As user I just use a new tool, that lets me attach one object to an other (like I now have a tool that joins segments to form a way - I don't have to handle the ids here too). --Kumakyoo 22:14, 7 May 2007 (BST)~

• For the purpose of discussion, how about a slightly different approach: Using your example, the contributor actually connects the highway to the subsidiary object using a segment or way (I prefer a segment for ease) and labels the segment subsidiary=yes. The connector always remains invisible when rendering but robustly preserves the relationship even if someone else does editting. It also means that the contributor does not need to know the id of the parent highway.

There are two other areas where this solution can be applied:

1) Associating an explicitly placed name tag with an area or linear way. For example, at the moment if you mark an area as amenity=parking in order to get it to render yellow, there is no explicit relation to a separate amenity=parking,name=Main Street Car Park tag needed to get the name and a "P" sign showing. This would also provide a solution for labelling motorway junctions with obscuring the junction itself - put the label off to one side and add a connector.

2) Associating useful secondary amenities that are inside something else. The prime example is a hotel (the parent node) that has a restaurant, atm machine and bar available for non-patrons.

MikeCollinson 18:06, 7 June 2007 (BST)

• I really like the way this is going actaully, linking objects removes the restriction of not being able to use a key twice, but still would keep things as a set. This should then remove the problem of people choosing on where to place things in order to get things to render well, as just adding things where they really are wouldn't make the render any better/worse. I asume this is all possible of corse in rendering terms/route planning etc? Ben 22:03, 7 June 2007 (BST)