[Tagging] Non-orthogonal crossing=* tag proposals: crossing=marked/unmarked vs crossing:markings=yes/no

[Warin]

On 25/05/19 07:32, Paul Allen wrote:
> On Fri, 24 May 2019 at 22:12, Kevin Kenny <kevin.b.kenny at gmail.com 
> <mailto:kevin.b.kenny at gmail.com>> wrote:
>
>
>     Yeah, there really are combinations around here:
>
>     does it have signs?
>     does it have traffic signals?
>     does it have specific pedestrian-facing traffic signals? (Some
>     intersections just have you cross at the same time as motor traffic in
>     your direction rolls)
>     are the traffic signals pedestrian- or cyclist-controlled? (Is there a
>     button for you to push?)
>     does it have pavement markings?
>

We also have;
tactile paving - a sequence of small raised bumps/dots on the paving 
that can be sensed by walkers/wheelchairs
audio warning - the button also has an audio output that signals when 
the traffic lights state to allow pedestrian crossing, and just before 
the pedestrian crossing closes.
>
> Some of those can probably be simplified away.  Like the push button.  
> It may
> seem like a major difference but in actuality on some crossings the ONLY
> purpose of the push button is to light the sign saying "Wait" and the 
> crossing
> cycle is determined by some combination of timing and traffic flow.
>
> I'd say that traffic/pedestrian signals is the key factor for 
> crossing=traffic_signals,
> irrespective of road decoration even if that road decoration modifies 
> the meaning
> of the signals in some way (it's effectively no different from a sign 
> on a pole).
> A marked crossing doesn't have traffic signals.  An unmarked crossing 
> doesn't
> even have markings.
>
> Pavement markings, tactile pavements, dropped kerbs, etc are all 
> attributes.  They
> don't turn it into a different type of crossing or (except possibly in 
> Poland) affect the
> interactions between pedestrians and motorists.  Nice to map, but as a 
> clarification,
> not a primary feature.
>
>     I'm fine with leaving crossing=* as it is for legacy compatibility,
>
>     but we *do* want to move toward orthogonality, since that's what we've
>     got on the ground.
>
>
> I'm not yet convinced there's orthogonality in crossing type (except 
> possibly in Poland).
> A crossing where the lights mean one thing and the road markings mean 
> a different
> thing doesn't strike me as being even remotely workable: the road 
> markings tell the
> pedestrians they have right of way irrespective of the lights and a 
> green light tells
> the motorist he has right of way.  That's no way to run a crossing.
>
> What we may need to do is expand on crossing_ref (maybe with a 
> different name) to cope
> with all the regional differences.  "This is a crossing controlled by 
> lights which just happens
> to have zebra stripes, but those stripes do not carry any legal 
> meaning and are purely
> decorative"  We almost certainly do need to distinguish between 
> Pelican and Puffin crossings
> in the UK because, although they look almost identical, the light 
> sequences and regulations
> differ.  Etc.
>
> -- 
> Paul
>
>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20190525/b324a2bf/attachment-0001.html>