[OSM-talk] Left and Right - a proposal

[Gervase Markham]

[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