On 22/09/2009, at 10:57 AM, Martin Koppenhoefer wrote:
> 2009/9/22 Anthony <o...@inbox.org>:
>> It is possible to represent different surfaces and different  
>> maxspeeds
>> without using more than one way.  "maxspeed:lane=130;110";
>> "surface:lane=asphalt;concrete".  That's not necessarily the best  
>> solution,
>
> indeed, it won't be understood by none of the apps that are using our
> data and it doesn't say, which lane has which value...

The first bit is always going to be a problem, however we decide to  
map lanes the tools will need changing. Special tags or relations?  
They'll need to parse those to be useful. A new database construct?  
They'll need to understand that. There is no way around needing to  
modify the tools if we want more than a pile of tags that somehow  
relate to ways.

The second bit we can easily get around by picking either counting  
from the left or right. Maybe something like lane[n]:key=value where  
there is data, and on the node in a way where the lanes change or  
merge we have lane-mapping data that says lane A back along the way  
changes to lane B after the way.


> but that's exactly what I propose (map lanes explicitly) and it's
> against the separate-ways-only-when-physically-divided-paradigm
> (because an ambulance could change from one way to another)...

There's a fun question, what counts as "physically divided"? I'm seen  
many emergency vehicles cross "physically divided" roads. If we  
exclude those, then what counts as a vehicle for the purposes of  
dividing a way? Are bicycles includes? Four-wheel drives?

> Usually there will be ~100mtres for this where you can
> change at any time, but in OSM you have to decide on one merging
> point.

I haven't seen a proposed scheme yet that really deals with this  
properly, they pretty much all pretend that a lane starts at a point.  
Personally I don't think that figuring this out is necessary for  
having multiple lanes, as we could continue the fiction that they  
start at a point. It'd be nice, but not necessary.

_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Reply via email to