I think Peter is spot on here. David
On 31/03/2008 15:59, Peter Miller wrote: > 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: [email protected] >> 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 > [email protected] > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
