Much encouraged that there is a coder (?) view that it's pretty simple to implement automated left /right tag reversal if a way is reversed (and I assume the main renderers are sense-aware where ways are concerned?). This was my main concern and if this is generally agreed to be the case I'll switch from the 'not sure' camp into the 'left / right' camp.
Mike Harris -----Original Message----- From: Andrew Chadwick [mailto:[email protected]] On Behalf Of Andrew Chadwick (email lists) Sent: 17 February 2009 13:25 To: [email protected] Cc: Mike Harris; 'David Earl'; 'Andy Allan'; 'Norbert Hoffmann' Subject: Re: [OSM-talk] [tagging] RFC :left/:right (asymmetrical roadside features) Mike Harris wrote: > While sympathetic to the underlying need being discussed in this > thread, I suspect there is a further problem. Although a way has an > intrinsic sense in OSM, this is fairly volatile! All it needs is > someone to reverse a way - and this can happen rather easily, say, > when combining two ways with the same tags but different senses (yes - > there is a warning but it's all too easy to click through). Reversing > the ways then, of course, reverses the 'left' and 'right' descriptors with > their differing tags! Yes, it'd be nice and simple to implement. Just swap any :left and :right -suffixed tags. That's why http://wiki.openstreetmap.org/wiki/Proposed_features/right_left#Consequences_for_software discusses it in some detail. If people whine about it enough, I'll make osm2go do something like this, as a sort of reference implementation :) We're probably being lazy about oneway, and I'm entirely in favour of building simple smarts like this into an editor that's as simple and Joe-Consumer-focused as osm2go: I want to make it difficult for Joe Consumer to do the wrong thing accidentally without getting in his/her face (no warning dialogs, just do the right thing given that there's a single, obvious, 99%-of-the-time right thing to do here) > This leads me to wonder > whether an absolute sense (north, south, etc.) is still better even > though it might require that a way is divided a bit. Most ways do have a > 'general' > compass direction for long segments even if this is often more > human-obvious than machine-obvious. The main exceptions are likely to > be short residential streets on housing developments etc. - 'circles' > etc. - but these are less likely to require unilateral tagging. Hmm. An argument from plausible estate design; innovative! :) For the reasons you stated, :north, :south etc would break down for some ways. Also, if an editor rotates the way, it'd also have to "rotate" some of the tags. Some of the time. It's really quite a bit more complicated than a :left/:right scheme for coding, and it doesn't buy you much more expressiveness. For points, it makes more sense. But pub:heading=<degrees> and pub:distance=<metres> would be finer-grained for those XD > Btw, I have encountered the same problem with canals. Some mappers > describe towpaths as being 'left' or 'right'. Personally, I prefer to > map the towpath as a separate way alongside the canal - with the added > advantage that this allows me to tag the towpath, e.g. with access > rights, surface condition, barriers, reference numbers, route relations, etc. For towpaths, I'd agree. They're 'sufficiently segregated' from the waterway in my head (you have to change mode fairly significantly to go from one to the other!) > Perhaps this would also be a better approach for e.g. cycleways > alongside motor roads? Although, I have to admit that it doesn’t solve > the problem of unilateral naming. Sometimes, sometimes not. Cycleways where you can/sometimes have to rejoin the ordinary carriageway should not be, :left and :right (or cycleway=opposite_*, broken though it is) do that more plausibly because then you're dealing with the same road. Cycleways that are long, continuous, separated by a grass verge, or go along the sides of 70MPH roads get the separate treatment when I tag them (often they need things like lit=yes/no too, those ones). -- Andrew Chadwick _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
