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 [EMAIL PROTECTED] ## N49°00'09" E008°23'33" _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk