[OSM-talk] Cycleways wiki doc enhanced

[Lester Caine]

Claus Hindsgaul wrote:
> 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.
THAT depends on a number of factors. If the cycleway is isolated from the road 
by a grass verge, then the U-turn may require getting off and carrying the bike. 
While a pedestrian could simply walk across. Cycle and pedestrian routing DOES 
require more information than is currently provided by a single vehicle way.

>     * The concept of being at the same road as the cars is lost:
>           o routing says something like "turn left at unnamed cycleway
>             one meter after Oxford Rd"
Currently in town pedestrian/cycle routing ASSUMES that the vehicle junctions 
are the same, which is often not the case. Directions can be just as wrong 
without providing separate ways. Adding ever more tags to describe details on 
routes which are NOT the same - although they may all be 'Uxbridge Road' - is 
simply wrong.

>           o 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.
One of the reasons *I* think that it is time 'highway' only referred to vehicle 
routes, and 'cycleway' and 'footway' were properly managed as separate ways? YES 
in some cases vehicle, cycle and foot traffic may well be on the same area of 
the earths surface, but where there are identified foot/cycle areas then these 
should be capable of being mapped, and then from that mapping data, lower zoom 
shorthand needs to understand the differences.

>           o traffic light count has the same problem
? a junction with slips and cycle boxes must be correctly mapped .... shorthand 
with two ways meeting with a 'traffic lights' tag is fine at the macro level, 
but then adding right/left turn slips and pedestrian/cycle islands need to be 
detailed.

>           o bicycle routing priority may not benefit from information
>             from the car way such as maxspeed, access or traffic density
Not sure what your point is here, but if in general there is a need to group 
elements together and apply tags at the higher level.

>           o bridge and tunnel rendering can not avoid to show several
>             separate bridges/tunnels for the same road due to missing
>             information
Or may actually REQUIRE a separate bridge or tunnel where the pedestrian/cycle 
route is separated for safety. The BRIDGE/TUNNEL element needs to be mapped 
properly, rather than just as a renaming of some area of a way! Just because the 
'shorthand' way of adding 'bridge' often gets the detail wrong just reinforces 
the need to properly map details.

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

I think this is the point.
Adding higher level tags that remove the need to map the lower level details 
simply creates more complexity when someone then comes to ADD the fine detail. 
The correct balance needs to be made, and having complex cycleway tags added to 
'third party' ways also needs to co-exist with actually mapping the cycleway. I 
don't see the creation of tags which then conflict with lower level mapping as 
an improvement. BUT if the tags relate to a shorthand FOR the lower level 
details and do not prevent actually adding the full detail, there is not a problem.

I was just concerned when it was being suggested that these REPLACE the lower 
level detail! They must not prevent the mapping of the actual fine detail.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php