[This post contains other people's ideas and points; thanks to all of them.]
It seems from the Left and Right discussion that there are many features we wish to map which are associated with the "side" of a way. This is a consequence of the fact that we are using things with zero width (ways) to represent real-world features which have a width (e.g. roads and canals). Examples include bus stops and shelters, parking restrictions and taxi ranks on roads, or mooring information, embankments and turning points on canals. Note that some of these are point features and others are length features. The key commonality is that *these are all things that would not be there if the way was not there*. This definition is what excludes phone boxes, post boxes etc. from needing this sort of association. (House numbers seem to me to be an edge case; let's leave that for now.) It seems to me that there are three ways we can deal with this: 0) Just place point features next to the way, with no explicit association apart from proximity. This is what we do now, and this lack of association causes problems. For linear features, you need to create a new, parallel way for that feature. Having to create this extra way is sub-optimal. One other problem with this is that it defines a set distance from the feature to the way. This means that, as you zoom out, the feature icon migrates onto the way itself as the way rendering "thickens". 1) Create relations to associate the point with the way - one relation per feature type, or perhaps a generic relation type. Except that relations are heavyweight things, complicated to set up (in current editors). And you still have the rendering problems described above. 2) The generic left-right scheme proposed below. Left/Right Scheme ----------------- I propose that it be possible for features to be tagged using a generic left/right scheme, with left and right being relative to the direction of the way. So you might have a road way with a node somewhere in the middle with (for example): left:highway=bus_stop right:parking=pay_and_display And a way which forms part of a canal might have (for example): right:mooring=24h left:embankment A key point here is that the logical place to put the information is not exactly the same as the logical place to put the icon representing it. We can put the information on the way, but renderers can put the icon next to the way (see below). This finesses the argument about whether we are mapping the place where the bus stops or the sign that tells us it's a bus stop. Any feature proposal would be able to say "uses the left/right scheme" to opt in to this generic mechanism. Changes Needed -------------- Renderers: Renderers would need to place the icon for the feature offset at right angles to the way, a feature-dependent distance, with a default for most features of "just far enough that the icon appears alongside the way", which is probably zoom-dependent. (This is a good thing - avoids the problems given above.) After moving the location, they render the feature as normal, as if a node were there. Renderers already have code for choosing a good location for icons for area features such as parking lots, so it'll be similar to that. Editors: Editors would need to switch "right" for "left" and vice versa in all tags when reversing a way. Note that this requires no special knowledge of what the prefixed tag means - that's why we have a generic mechanism. They might also apply this switching to some special cases such as "oneway". What do people think? Gerv _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
