[OSM-talk] Cycleways wiki doc enhanced
lester at lsces.co.uk
Sat Jan 2 14:19:08 GMT 2010
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
> 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
> 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
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
More information about the talk