Can I suggest that the vehicle oneway=yes/no attribute should be able to take an additional value of 'reverse' to make all the tags independent of the direction of the way and avoid the need to reverse ways at all. I do agree that attributes should use prefix values of forwards/backwards and left/right and that editors should reverse these if the way is reversed.
Btw, this approach is used by GDF where a direction attribute is used which can take the values 'traffic is allowed in both directions', 'traffic is closed in the positive direction', 'traffic is closed in the negative direction' and 'traffic is closed in both directions' (9.3.6). I believe that this attribute in GDF can be used in conjunction with a vehicle class to create different rules for different types of vehicle (including pedestrians and cyclists). With regard to the debate about separate tracks or a 'handed' attributes for the road I would suggest that there are times where either might be appropriate, but that it would be reasonably easy to create a separate track automatically from a 'handed attribute' if required (and would be much easier than the reverse transformation) so the handed approach should be preferred. I also suggest that it will be easier for the renderer to encode parallel cycle lanes on cycle maps using the convention of colour coding the casing of the road if the handed approach is used. Currently there are a lot of problems with separate cycle tracks close to roads getting obscured by the road itself or indeed obscuring the road. Personally I will continue to use handed attributes where the track is parallel to the road and where there is no barrier between the track and the road (other than some grass and a kerb). Fyi, the Cycle Data Standard for the Department for Transport in the UK that I worked on in the autumn used the concept of an 'offset path' which had is own identity (and could therefore be used in relationships) but which borrowed its geometry from the main way to avoid all the problems of stitching the way into all the side streets and to allow 'casing colour' style maps to be created. I am requesting that they publish the standard so we can compare and contrast and will let you know when it becomes available. Regards, Peter Miller > Message: 1 > Date: Mon, 31 Mar 2008 11:41:26 +0000 (UTC) > From: David Dean <[EMAIL PROTECTED]> > Subject: Re: [OSM-talk] Cycle lanes > To: talk@openstreetmap.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > Martin Vidner <martin.osm <at> vidner.net> writes: > > > Make the prefixes "left:", "right:" special in the sense that when a > > way is reversed, they get swapped. > > So left:highway=bus_stop would become right:highway=bus_stop. > > (Uh, maybe this is awkward for the renderer implementation. Could be > > better to prefix the *value* instead: highway=left:bus_stop?) > > > It seems to me that you could define the two sides of a way independent of > the > direction (if any) of the way. I'm just not sure what you would call the > two > sides. > > For example, lets start with "north" and "south". This would unambiguously > define the two sides for all ways that are not running directly (or close > to) > north-south. "East" and "west" would work for those of course, but we want > the > same name no matter what the angle of the road. > > Maybe you could use "clockwise" and "anticlockwise" to define the side of > that > portion of the road you would get if you rotated it in that direction. > > So what I am basically getting at is that you don't need to define the > side of > the road based on the way direction, as it can be defined by the compass > points, > I'm just not sure what the two labels would be. Maybe "north-or-east" and > "south-or-west" shortened to "noe" and "sow" could work if everything was > clearly defined on the wiki. > > - David > _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
