[OSM-talk] Left and Right - a proposal

[Frederik Ramm]

Hi,

> Why so? The direction of ways is (or can be) indicated with arrows in
> editors.

Yes but talking of a "left" and "right" side of a road, in everyday 
speech, alway means "in the direction of travel". We're used to saying 
"the Britons drive on the left", which is a different use of the terms 
than you want to establish.

> Why is it a problem to have tagging which is
> way-direction-dependent? We already have it with e.g. oneway.

I don't like oneway that much either, but at least (ignoring "oneway=-1" 
for a moment) this is a situation where the situation on the ground 
gives a very strong indication of the way direction (much like rivers 
and unlike any normal road).

My major problem with attaching significance to the direction of ways is 
the ease with which that direction can and will be changed. We will 
never have API support for juggling around all sorts of left/right tags 
(plus oneway, incline and what-have-you), so this is the burden of the 
editing software. I think it is realistic to assume that there will 
always be some editors which do not properly implement any rules that 
you might define regarding left/right tagging - be that due to 
misunderstandings, incompleteness, or just bugs.

The less important the direction of a way is, the less fragile the 
system becomes vis-a-vis non-complying editors, people writing robots, 
and the like. I don't think we have the manpower to set up an "editor QA 
task force", nor would it be in the spirit of the project to grant edit 
access only to approved software (who would set the rules, who would 
approve, etc.etc.).

> I am not suggesting that maps would ever use the terms "left" and
> "right" with relation to such tagging. You are right, that would be very
> confusing. But for people editing the data, when the way has a clear
> direction  I can't think of two better terms to use.
> 
> What terms would you use?

I would certainly not use any terms that somehow relate to the direction 
of the way. If I wanted some sort of informal relative positioning I 
would probably go with compass directions, splitting the way in those 
rare cases where it is shaped too funny for this to work.

That being said, I tend to take the long-term view; I firmly believe 
that the time of linear features will be over soon and we'll have more 
and more areas (e.g. rivers and roads - this is starting already with 
large rivers and roads becoming plazas; but I'm sure it will happen for 
ALL rivers and ALL roads). Of course this needs good editor support to 
prevent one from going crazy. Phone booths and post boxes will remain 
point features for some time, but bus stops will (IMHO) definitely 
become areas. We will then still need a relation that combines the road 
area and the bus stop area, saying: "These are not independent of each 
other; they are meant to be adjacent, and dear editor, if you move one, 
please move the other as well".

If I were you I'd map all the relevant canal details as areas even 
today. Because it is going to happen anyway - if you spend a lot of 
effort to map it as a point feature today, someone else is going to make 
an area of it in a few months' time.

I suspect this might not seem right to you because you have a certain 
map representation in mind but there's no written rule that anything 
drawn as an area must also be rendered as one; it is obvious that in the 
long run renderers will need (and get) mechanisms to collapse areas into 
lines or points at low-detail zoom levels.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"