2010/1/2 Lester Caine <span dir="ltr"><<a href="mailto:lester@lsces.co.uk">lester@lsces.co.uk</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Provided that this does not result in REMOVING ways that are mapped - or prevent<br>
adding the REAL fine detail of ways that do not actually physically form part of<br>
the 'accompanying' road. This sort of 'shorthand' should not replace mapping the<br>
real situation on the ground ESPECIALLY where the cycleway ( or<br>
sidewalk/footpath ) is not physically part of the 'accompanying' road.<br>
<br>
NOTHING should dictate that removing physical data is the 'correct' way of mapping!<br></blockquote><div><br>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.<br>

<br>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. <br>

<br>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:<br>

<ul><li>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.</li><li>The concept of being at the same road as the cars is lost:</li><ul><li>routing says something like "turn left at unnamed cycleway one meter after Oxford Rd"</li>
<li>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.<br>

</li><li>traffic light count has the same problem<br></li><li>bicycle routing priority may not benefit from information from the car way such as maxspeed, access or traffic density</li><li>bridge and tunnel rendering can not avoid to show several separate bridges/tunnels for the same road due to missing information<br>


</li></ul></ul>This is just to illustrate that it does not always lead
to better map data to choose the most labour intensive and complex
representation.<br>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.<br>

<br>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.<br>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.<br> </div></div>-- <br>-- <br>Civilingeniør ph.d. Claus Hindsgaul<br>Edvard Thomsens Vej 19, 5. th<br>DK-2300 KBH S<br>