[OSM-talk] Cycleways wiki doc enhanced

[Claus Hindsgaul]

2010/1/2 Lester Caine <lester at lsces.co.uk>

>
> Provided that this does not result in REMOVING ways that are mapped - or
> prevent
> adding the REAL fine detail of ways that do not actually physically form
> part of
> the 'accompanying' road. This sort of 'shorthand' should not replace
> mapping the
> real situation on the ground ESPECIALLY where the cycleway ( or
> sidewalk/footpath ) is not physically part of the 'accompanying' road.
>
> NOTHING should dictate that removing physical data is the 'correct' way of
> mapping!
>

I don't think anyone here wants to erase good information from the map. But
unless we are prepared to reconsider implementations, OSM is bound to lack
evolution and be increasingly inconsistent as we gain more experience and
learn from each other.

Correct me if I am wrong, but I assume that you want to impose a regime,
where tags can be altered or (in the case of cycleways) can be converted to
separate ways - but that it is NEVER an improvement to delete a separate way
("physical data") and replace it by "shorthand" cycleway-tags.

If so, I have to disagree. In many cases separate ways or nodes indeed adds
information and refine the digital map description. But at least with cycle
tracks aligned with roads, I think it often really REMOVES more information
than it adds, at least for routing software. These are examples of
information that you throw away if you separate a closely coupled cycleway
from its road:

   - There is no way for routing software to deduct that you can cross the
   road to access the opposite track or the road itself e.g. to make a U-turn,
   until you reach a junction.
   - The concept of being at the same road as the cars is lost:
      - routing says something like "turn left at unnamed cycleway one meter
      after Oxford Rd"
      - junction count will be screwed. Information such as "turn right at
      the 3rd junction" can not be deducted from the map data as extra
      highway=cycleway and possibly future sidewalk-ways intoxicate it.
      - traffic light count has the same problem
      - bicycle routing priority may not benefit from information from the
      car way such as maxspeed, access or traffic density
      - bridge and tunnel rendering can not avoid to show several separate
      bridges/tunnels for the same road due to missing information

This is just to illustrate that it does not always lead to better map data
to choose the most labour intensive and complex representation.
For most closely coupled bicycle tracks/lanes I myself would clearly prefer
the "cycleway=track/lane" representation to separate ways EVEN if it took
more time and effort to do! (My post from yesterday lists the obvious
exceptions). It is not just a shorthand as you seem to imply.

I will not advocate an invasive general mass conversion, but trust that
mappers will continue to evaluate improve the implementation of their future
and former contributions based on insights from the community.
We should not dictate removing existing ways, but neither should we forbid
improving the representation where applicable, even if this involves
conversion of existing separate cycleways to cycleway-tags.

-- 
-- 
Civilingeniør ph.d. Claus Hindsgaul
Edvard Thomsens Vej 19, 5. th
DK-2300 KBH S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20100102/6437f577/attachment.html>