[OSM-talk] Lane turn restrictions

Aun Johnsen (via Webmail) skippern at gimnechiske.org
Fri Aug 21 00:41:22 BST 2009


On Fri, 21 Aug 2009 07:48:18 +1000, Roy Wallace <waldo000000 at gmail.com>
wrote:
> On Fri, Aug 21, 2009 at 6:11 AM, Tobias Knerr<osm at tobias-knerr.de> wrote:
>>
>> I believe it fits the project's general spirit to allow mappers to
>> choose their level of detail (and other mappers to increase it if they
>> are ready to invest the time).
> 
> +1
> 
>> Lod steps could be described as
>>
>> 1. road without lane detail
>> 2. road with partial lane data (think cycleway=lane)
>> 3. road with full lane data, but no lane geometry
>> 4. road with full lane data and partial lane geometry (e.g. individual
>> ways only for pavements and bicycle lane, but not for the perfectly
>> parallel car lanes)
>> 5. road with full lane data and geometry
> 
> So, the question becomes, which of the above are already achievable/in
> use with existing tags, which are in proposal stage, which need new
> proposals.
> 
> And then back to the question, how to model LTR (lane turn
> restrictions) for ways with each of the above LOD's (level of detail).
> Obviously at least LOD 2 will be required. But we may find that it's
> only possible to model LTRs simply for ways with LOD 3 or above.
> 
As I see it, the tag lane=* can give enough information to how to number
the lanes, if there are 3 lanes in the same direction number them 1 - 3
Left to Right. A lane turn restriction should be able to use these numbers
in the roles in some way, and continue to work the same way as normal turn
restrictions.

member=someway1 role=from.1 (from lane 1)
member=someway2 role=to.3 (into lane 3 of the other way)
member=somenode role=via (the intersection)

This approach shouldn't require too much complications for rendering,
routing, and so on. An editor might even be able to check if the lane
exists (with lane=* tag) in the to and from members.

For the example previously in this thread, I think some grouping can be
done, such as all lanes between two physical dividers should be tagged as
one way, and all physical barriers that have a sensible tag should be
tagged as such. A small curb and such barriers should not be tagged, but
putting two highway=primary + oneway=yes in same direction parallel would
indicate something like that. When such models becomes complicated,
intersections needs to be grouped in special ways, maybe an intersection
relation or an area tag?

-- 
Brgds
Aun Johnsen
via Webmail




More information about the talk mailing list