Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

I agree that it's very confuddled. I'm going to start a new thread soon
after I make some updates to the proposal, primarily for clarity and
covering some of the most common questions that have come up here. I'd like
to steal your examples, if you don't mind, for the wiki.

The response you received about specific tagging strategies seem roughly in
line with how I'd map, although I shy away from crossing=traffic_signals
due to the various previously stated reasons, although I personally focus
on mapping ways over nodes. Not that there's anything wrong with adding the
same information to a node, it's just not my focus.

Were this and the other proposal about traffic_signals adopted, your
questions would be a bit easier to answer:

(1) Is the crossing marked? If so, crossing=marked. If not,
crossing=unmarked
(2) Does the crossing have a pedestrian light (that is synchronized with a
traffic-facing stop/go light)? crossing:*signals=yes (I am going to rework
the crossing:signals proposal to distinguish pedestrian from traffic).

The only exception is the path through a parking lot that you noted. I
think that's a case that could potentially use its own new tag of some kind
- a marked path through a shared pedestrian/car space. I wouldn't tag it as
anything other than highway=footway for now.

On Sun, May 12, 2019 at 1:50 PM Kevin Kenny  wrote:

> This discussion is leaving me pretty bewildered.
>
> Sometimes my bewilderment can be alleviated by considering concrete
> examples.
>
> On my walk yesterday, other than the implied crossing at every
> intersection (but see "don't map local law") I noted the following:
>
> 1. Combined foot/cycle crossing - a side path from a combined
> foot/cycleway onto a very lightly trafficked suburban street. Marked
> with signs bearing the silhouette of a bicycle about 50 m in advance
> of the crossing. No markings on the pavement. (This crossing is part
> of my daily commute. The street that it crosses is quite busy, and the
> sign with the bicycle silhouette has no apparent effect on the
> drivers. Pedestrians divide into the quick and the dead.)
>
> 2. Combined foot/cycle crossing - a combined foot/cycleway crossing a
> busy two-lane street at grade. Signage both ~50 m in advance and at
> the crossing. Flashing yellow lights (meaning 'proceed with caution')
> flank the sign at the crossing. The lights can by turned on by a
> pedestrian or cyclist pushing a button. Zebra-stripe pavement
> markings.
>
> 3. Zebra-stripe pavement markings at an intersection controlled by a
> 4-way STOP sign.
>
> 4. Zebra-stripe pavement markings at an intersection controlled by a
> traffic light, with no 'WAIT/WALK' pedestrian signals.
>
> 5. Zebra-stripe pavement markings at an intersection controlled by a
> traffic light, with 'WAIT/WALK' pedestrian signals, and a countdown
> timer giving the seconds remaining to cross.
>
> 6. The same, with the pedestrian or cyclist requesting the WALK signal
> by pressing a button.
>
> 7. Zebra-stripe pavement markings, together with a sign displaying the
> silhouette of school children, in the middle of a block in front of a
> school. This crossing may be supervised during school
> arrival/departure times.
>
> 8. Zebra-stripe pedestrian markings delineating the preferred footpath
> in a parking field, and running generally perpendicular to the parking
> aisles.
>
> And I'm now in confusion about how to tag any of them.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[John Willis via Tagging]

When mapping in Japan, I map all sidewalks. as a Califorinian, where sidewalks 
are common and usually follow the road alignment at all times, I understand 
OSM’s tenancy to map sidewalks are merely an attribute of the road - but when 
dealing with the sidewalks in Japan, they oftentimes follow their own 
alignments and take shortcuts roads cannot - or are abruptly ended to force 
peds onto footbridges, tunnles, or alrernate routes.

almost all minor and residential roads have no shoulders nor sidewalks, so this 
applies to tertiary and above. 

my best friend, by far, is “unmarked crossing”

Here’s one, doing it’s job. 

https://www.openstreetmap.org/way/689318021#map=17/36.61939/140.15490 


Think about how a ped would get to Nikko station from a school or park on the 
east side of the river - the route they would take is very different than the 
route of a car. 

This applies to *so many places* in suburban Japan, not just Tokyo or other 
city centers. small farming towns have irregular ped access - all of it must be 
mapped (where I am). 

when linking sidewalks to roads, usually where sidewalks abruptly end, or where 
a street intersects with the road (but not the sidewalk), I will use unmarked 
crossing to allow proper routing of foot routers. 

https://www.openstreetmap.org/way/490803227 


one sidewalk abruptly ends, and people will cross over to the other. this also 
links in into the road, but still illustrating the end of the actual sidewalk 
. 


https://www.openstreetmap.org/way/490803228#map=19/36.42382/137.87325 


a hundred meters away from the one above. a T intersection has a sidewalk that 
dead-ends. people will cross the street to the other sidewalk (and the other 
other road. a crossing is appropriate but unpainted. 



https://www.openstreetmap.org/way/689318021#map=17/36.61939/140.15490 



This section of sidewalk (including the continued segments on either end of it) 
exemplifies the sidewalks of Japan:

they begin and end with no warning, dumping any foot traffic into the road (not 
the shoulder, but into a car lane). 

- they do not interact well with roads that “T” into their parallel street (no 
consideration for peds trying to cross the road there, unless there is a 
crosswalk)

- larger ones are used as agricultural access as well. this is true of cycling 
roads too.

the “unmarked crossing” is how I link these back into the road, how I put a 
connection to roads that peds would like to access but is not served by a 
crosswalk, and how I mark where they end when the road interrupts them at a 
common intersection - 

“unmarked crossing” is my “unpainted crosswalk”  and “sidewalk link” 
substitution.

Javbw

 

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Graeme Fitzpatrick]

On Tue, 14 May 2019 at 18:38, Volker Schmidt  wrote:

> NB: This crossing is not mapped correctly in OSM as there is no common
> node betweet crossing footway and crossed road.
>

Correct!

But when I mapped it, those errors weren't coming up - there's lot's that
I've got back & "join" :-(

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Graeme Fitzpatrick]

On Tue, 14 May 2019 at 17:23, Warin <61sundow...@gmail.com> wrote:

> On 14/05/19 17:14, osm.tagg...@thorsten.engler.id.au wrote:
>
> Haven’t checked if it shows up as an error, but technically, the grass on
> each side is the “sidewalk”, and it is simply a shortcoming of the current
> tagging schemes that it’s not possible to properly tag it as pedestrian
> routable area.
>
>
> Why not?
> highway=footway/path surface=grass
> Or for sidewalk sidewalk:both:surface=grass
>

Yes, I suppose we could, but then pretty well every residential street will
have a footpath / sidewalk each side.

Isn't that then going to hide the "real" (concrete etc) footpaths that
people want / need to use?

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Volker Schmidt]

On Tue, 14 May 2019 at 05:10,  wrote:
>
> I must admit that I only map crossings when they are between formed
> footpaths eg
>
> https://www.openstreetmap.org/way/553154851, not where there is only a
> grass footpath.
>
NB: This crossing is not mapped correctly in OSM as there is no common node
betweet crossing footway and crossed road.

Volker
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Martin Koppenhoefer]

sent from a phone

> On 14. May 2019, at 09:16,  
>  wrote:
> 
> People do generally walk on this “grass” sidewalk.


they could, but if they would, it would not remain grass ;-)

Cheers, Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Warin]

On 14/05/19 17:14, osm.tagg...@thorsten.engler.id.au wrote:


Haven’t checked if it shows up as an error, but technically, the grass 
on each side is the “sidewalk”, and it is simply a shortcoming of the 
current tagging schemes that it’s not possible to properly tag it as 
pedestrian routable area.




Why not?
highway=footway/path surface=grass
Or for sidewalk sidewalk:both:surface=grass
   ???

These lowered kerbs represents points with easy access from sidewalk 
to street for wheelchair users or people pushing prams, and I think 
it’s worthwhile to map them.


*From:*Graeme Fitzpatrick 
*Sent:* Tuesday, 14 May 2019 10:24
*To:* Tag discussion, strategy and related tools 


*Subject:* Re: [Tagging] Feature Proposal - crossing=marked


On Tue, 14 May 2019 at 05:10, <mailto:osm.tagg...@thorsten.engler.id.au>> wrote:


I must admit that I only map crossings when they are between formed 
footpaths eg


https://www.google.com/maps/@-28.070784,153.4361817,3a,75y,133.97h,57.19t/data=!3m6!1e1!3m4!1saeYx4cpvnikG8KXcdh0pGw!2e0!7i13312!8i6656 
<https://www.google.com/maps/@-28.070784,153.4361817,3a,75y,133.97h,57.19t/data=%213m6%211e1%213m4%211saeYx4cpvnikG8KXcdh0pGw%212e0%217i13312%218i6656> 



https://www.openstreetmap.org/way/553154851, not where there is only a 
grass footpath.


I do generally map crossings as long as they have lowered kerbs,
like here:


https://cdn.discordapp.com/attachments/558999688670609448/577570543851536401/unknown.png

That one, I would have terminated the crossing at the marked road, 
rather than taking it to the other side


or even:


https://cdn.discordapp.com/attachments/558999688670609448/577571624585527296/unknown.png

& that I wouldn't have marked at all. Does it show up in OSMose / OSM 
Inspector etc as an error because it's not "attached" to anything?


Thanks

Graeme



https://www.openstreetmap.org/node/6465544169





___
Tagging mailing list
Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[osm.tagging]

People do generally walk on this “grass” sidewalk.

 

From: Martin Koppenhoefer  
Sent: Tuesday, 14 May 2019 16:04
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Feature Proposal - crossing=marked

 

 

sent from a phone


On 14. May 2019, at 02:24, Graeme Fitzpatrick mailto:graemefi...@gmail.com> > wrote:

https://cdn.discordapp.com/attachments/558999688670609448/577570543851536401/unknown.png

 

That one, I would have terminated the crossing at the marked road, rather than 
taking it to the other side

 

 

the lowered kerb clearly indicates a crossing though - unlike the grass surface 
on the „footpath“ which seems to indicate that nobody is actually walking there 
;-)

 

Cheers, Martin 

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[osm.tagging]

Haven’t checked if it shows up as an error, but technically, the grass on each 
side is the “sidewalk”, and it is simply a shortcoming of the current tagging 
schemes that it’s not possible to properly tag it as pedestrian routable area.

 

These lowered kerbs represents points with easy access from sidewalk to street 
for wheelchair users or people pushing prams, and I think it’s worthwhile to 
map them.

 

From: Graeme Fitzpatrick  
Sent: Tuesday, 14 May 2019 10:24
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Feature Proposal - crossing=marked

 




 

On Tue, 14 May 2019 at 05:10, mailto:osm.tagg...@thorsten.engler.id.au> > wrote:

 

I must admit that I only map crossings when they are between formed footpaths eg

 

https://www.google.com/maps/@-28.070784,153.4361817,3a,75y,133.97h,57.19t/data=!3m6!1e1!3m4!1saeYx4cpvnikG8KXcdh0pGw!2e0!7i13312!8i6656
 

 

https://www.openstreetmap.org/way/553154851, not where there is only a grass 
footpath.

 

I do generally map crossings as long as they have lowered kerbs, like here:

https://cdn.discordapp.com/attachments/558999688670609448/577570543851536401/unknown.png

 

That one, I would have terminated the crossing at the marked road, rather than 
taking it to the other side

 

or even:

https://cdn.discordapp.com/attachments/558999688670609448/577571624585527296/unknown.png

 

& that I wouldn't have marked at all. Does it show up in OSMose / OSM Inspector 
etc as an error because it's not "attached" to anything?

 

Thanks

 

Graeme

 



https://www.openstreetmap.org/node/6465544169





___
Tagging mailing list
Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org> 
https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Martin Koppenhoefer]

sent from a phone

On 14. May 2019, at 02:24, Graeme Fitzpatrick  wrote:

>> https://cdn.discordapp.com/attachments/558999688670609448/577570543851536401/unknown.png
> 
> That one, I would have terminated the crossing at the marked road, rather 
> than taking it to the other side


the lowered kerb clearly indicates a crossing though - unlike the grass surface 
on the „footpath“ which seems to indicate that nobody is actually walking there 
;-)

Cheers, Martin ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Graeme Fitzpatrick]

On Tue, 14 May 2019 at 05:10,  wrote:

I must admit that I only map crossings when they are between formed
footpaths eg

https://www.google.com/maps/@-28.070784,153.4361817,3a,75y,133.97h,57.19t/data=!3m6!1e1!3m4!1saeYx4cpvnikG8KXcdh0pGw!2e0!7i13312!8i6656


https://www.openstreetmap.org/way/553154851, not where there is only a
grass footpath.


> I do generally map crossings as long as they have lowered kerbs, like here:
>
>
> https://cdn.discordapp.com/attachments/558999688670609448/577570543851536401/unknown.png


That one, I would have terminated the crossing at the marked road, rather
than taking it to the other side


> or even:
>
>
> https://cdn.discordapp.com/attachments/558999688670609448/577571624585527296/unknown.png


& that I wouldn't have marked at all. Does it show up in OSMose / OSM
Inspector etc as an error because it's not "attached" to anything?

Thanks

Graeme


>
> https://www.openstreetmap.org/node/6465544169
>
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[osm.tagging]

Forgot that part:

> On my walk yesterday, other than the implied crossing at every
> intersection (but see "don't map local law") I noted the following:

I do generally map crossings as long as they have lowered kerbs, like here:

https://cdn.discordapp.com/attachments/558999688670609448/577570543851536401/unknown.png

or even:

https://cdn.discordapp.com/attachments/558999688670609448/577571624585527296/unknown.png

https://www.openstreetmap.org/node/6465544169





___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[osm.tagging]

> 1. Combined foot/cycle crossing - a side path from a combined
> foot/cycleway onto a very lightly trafficked suburban street. Marked
> with signs bearing the silhouette of a bicycle about 50 m in advance
> of the crossing. No markings on the pavement. (This crossing is part
> of my daily commute. The street that it crosses is quite busy, and
> the sign with the bicycle silhouette has no apparent effect on the
> drivers. Pedestrians divide into the quick and the dead.)

On the intersection node between footway and road way:
highway=crossing
crossing=unmarked

You may tag the traffic_sign (here and in other cases) separately, how to do 
that is topic all it's own.

> 2. Combined foot/cycle crossing - a combined foot/cycleway crossing
> a busy two-lane street at grade. Signage both ~50 m in advance and
> at the crossing. Flashing yellow lights (meaning 'proceed with
> caution') flank the sign at the crossing. The lights can by turned
> on by a pedestrian or cyclist pushing a button. Zebra-stripe
> pavement markings.

On the intersection node between footway and road way:
highway=crossing
crossing=uncontrolled (or crossing=zebra)

You may tag the traffic_sign separately

> 3. Zebra-stripe pavement markings at an intersection controlled by a
> 4-way STOP sign.

On the intersection node between footway and roadway:
highway=crossing
crossing=uncontrolled (or crossing=zebra)

On a separate node on the road way placed at the stop line:
highway=stop (This tag is a big ugly like that, because it depends on consumers 
figuring out in what direction it applies based on proximity to the 
intersection, but again, that's a topic all it's own.)

(And additionally, given that this is specifically an all way stop, on the 
intersection node of the two road ways:
highway=stop
stop=all

> 4. Zebra-stripe pavement markings at an intersection controlled by a
> traffic light, with no 'WAIT/WALK' pedestrian signals.

On the intersection node between footway and road way:
highway=crossing
crossing=uncontrolled (or crossing=zebra)

Either on the intersection node of the two road ways, or if dual carriage, on 
separate nodes on the road ways placed at the stop line (coming into the 
junction):
highway=traffic_signals

> 5. Zebra-stripe pavement markings at an intersection controlled by a
> traffic light, with 'WAIT/WALK' pedestrian signals, and a countdown
> timer giving the seconds remaining to cross.

On the intersection node between footway and road way:
highway=crossing
crossing=traffic_signals

Either on the intersection node of the two road ways, or if dual carriage, on 
separate nodes on the road ways placed at the stop line (coming into the 
junction):
highway=traffic_signals

> 6. The same, with the pedestrian or cyclist requesting the WALK
> signal by pressing a button.

On the intersection node between footway and road way:
highway=crossing
crossing=traffic_signals

If the pedestrians HAVE to push the button to get a WALK (not just "can push, 
which may make it faster or just be a placebo [more common than you think]"), 
also:
button_operated=yes

Either on the intersection node of the two road ways, or if dual carriage, or 
if dual carriage, on separate nodes on the road ways placed at the stop line 
(coming into the junction):
highway=traffic_signals

> 7. Zebra-stripe pavement markings, together with a sign displaying
> the silhouette of school children, in the middle of a block in front
> of a school. This crossing may be supervised during school
> arrival/departure times.

on the intersection node between footway and roadway:
highway=crossing
crossing=uncontrolled (or crossing=zebra)

maybe:
supervised=(valid time expression)

> 8. Zebra-stripe pedestrian markings delineating the preferred
> footpath in a parking field, and running generally perpendicular to
> the parking aisles.

If there is no intersecting node between this way and a road way, then this is 
not a crossing, it's just a footway that happens to be marked using zebra 
stripe pattern.

If there IS an actual intersection between this way and a roadway, then the 
same as any other such crossing, on the intersection node between footway and 
road way:
highway=crossing
crossing=uncontrolled (or crossing=zebra)

> And I'm now in confusion about how to tag any of them.

For all of these, if you want to go down into micromapping territory, in 
addition to the above:
2 nodes on the footway, where the footway crosses the kerb on either side of 
the street with:
barrier=kerb
kerb=lowered (if it is, other values otherwise obviously)
(if the kerb itself is mapped as a way, then these two nodes are the 
intersection nodes between the footway and the kerb way)

and the part of the footway between the two kerb nodes (with the 
highway=crossing node being between them along this way), split at the kerb 
nodes and tagged as:
highway=footway
footway=crossing
crossing=(whatever it is)




___
Tagging mailing list

Re: [Tagging] Feature Proposal - crossing=marked

[Kevin Kenny]

This discussion is leaving me pretty bewildered.

Sometimes my bewilderment can be alleviated by considering concrete examples.

On my walk yesterday, other than the implied crossing at every
intersection (but see "don't map local law") I noted the following:

1. Combined foot/cycle crossing - a side path from a combined
foot/cycleway onto a very lightly trafficked suburban street. Marked
with signs bearing the silhouette of a bicycle about 50 m in advance
of the crossing. No markings on the pavement. (This crossing is part
of my daily commute. The street that it crosses is quite busy, and the
sign with the bicycle silhouette has no apparent effect on the
drivers. Pedestrians divide into the quick and the dead.)

2. Combined foot/cycle crossing - a combined foot/cycleway crossing a
busy two-lane street at grade. Signage both ~50 m in advance and at
the crossing. Flashing yellow lights (meaning 'proceed with caution')
flank the sign at the crossing. The lights can by turned on by a
pedestrian or cyclist pushing a button. Zebra-stripe pavement
markings.

3. Zebra-stripe pavement markings at an intersection controlled by a
4-way STOP sign.

4. Zebra-stripe pavement markings at an intersection controlled by a
traffic light, with no 'WAIT/WALK' pedestrian signals.

5. Zebra-stripe pavement markings at an intersection controlled by a
traffic light, with 'WAIT/WALK' pedestrian signals, and a countdown
timer giving the seconds remaining to cross.

6. The same, with the pedestrian or cyclist requesting the WALK signal
by pressing a button.

7. Zebra-stripe pavement markings, together with a sign displaying the
silhouette of school children, in the middle of a block in front of a
school. This crossing may be supervised during school
arrival/departure times.

8. Zebra-stripe pedestrian markings delineating the preferred footpath
in a parking field, and running generally perpendicular to the parking
aisles.

And I'm now in confusion about how to tag any of them.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Martin Koppenhoefer]

sent from a phone

> On 12. May 2019, at 21:27, Nick Bolten  wrote:
> 
> Regarding an "uncontrolled pedestrian crossing", keep in mind that the wiki 
> calls a crossing "uncontrolled" if it just has markings on the ground, which 
> disagrees with what uncontrolled actually means everywhere else.


people are using “uncontrolled” for all kind of zebra crossings in the areas I 
am familiar with, also those with vertical signs and eventually flashing 
warning lights. I’ve also done this myself for years, but I agree it doesn’t 
make sense.

Cheers, Martin 



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Martin Koppenhoefer]

sent from a phone

> On 12. May 2019, at 21:27, Nick Bolten  wrote:
> 
> It's easy to sympathize: we've got a tag about a *crossing* specifying 
> *traffic* signals, but not the exact kind of traffic (pedestrians are also 
> referred to as traffic) nor signal type aside from it being lights.


I never had any doubts that the signals would be controlling all traffic that 
meets at the crossing, including pedestrians. Actually I’ve seen the node with 
crossing=traffic_signals as the traffic lights for the pedestrians. The traffic 
lights for the “cars” can either be explicitly mapped or be implicit. If you 
see need to state this explicitly, you can do it, I would not expect any 
complaints about such an edit.

For signal types I suggest to use a subtag, while it may be interesting to some 
people, it isn’t adding significant information for many other use cases.

Cheers, Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

> hm, would you consider these traffic lights, or not? It basically depends
on this interpretation whether you should use a different tag or would use
crossing=traffic_lights If you decide for the latter it could still make
sense to add another tag for the specific crossing (sub)type.

Personally, if someone said, "look at that traffic light", I'd assume it
was a light that tells cars when to stop and go and I'd imagine red, amber,
and green lights. I would not think of warning signals as a traffic light,
so I'd need to visit the wiki and try to guess about what tag to use, if
any.

Let's say we did make another tag: crossing=warning_lights. We'd actually
have made the overall problem worse by adding a tag that doesn't describe
pedestrian signals or markings on the ground, forcing mappers to choose
between the types of information they can map.

After these discussions, my preference is for a unique tag for street
traffic signals at crossings:
crossing:street_signal=yes/no/traffic_lights/warning/*, with wording up for
debate.


On Sat, May 11, 2019 at 6:41 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 11. May 2019, at 01:42, Nick Bolten  wrote:
> >
> > Having trouble finding a good picture (I'll keep looking), but there are
> mid-block crossings where pedestrians can press an APS to turn on traffic
> warning lights - usually yellow in the US. Some of these crossings do not
> immediately give you those traffic warnings lights, but instead are tied to
> nearby traffic and turn on after a delay. When the lights turn on, there is
> some form of a pedestrian signal: sometimes the APS talks to you, sometimes
> there's a visual cue: lights turn on or a "walk" sign enables
>
>
> hm, would you consider these traffic lights, or not? It basically depends
> on this interpretation whether you should use a different tag or would use
> crossing=traffic_lights
> If you decide for the latter it could still make sense to add another tag
> for the specific crossing (sub)type.
>
> Cheers, Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

> If the light is purely a warning to both traffic and pedestrians, then
it's not crossing=traffic_signals. If it controls both traffic and
pedestrians (control as in indicating whether they should halt or proceed)
then it's crossing=traffic_signals.  Your situation of warning lights for
traffic strikes me as bizarre and could be argued either way.  Or maybe it
needs crossing=insane_signals.

I think it should be a completely separate tag that specifies exactly what
traffic is being controlled, and by what, with optional levels of
specificity, like most other tags. I would rather have
crossing:stop_sign=no and crossing:street_signals=hawk than
crossing=traffic_signals, for example, because at least everyone can know
what the former means. They can even be presented as simple yes/no
questions.

> I think the clue is in the name: crossing=TRAFFIC_signals.  Also
CROSSING=traffic_signals.  And crossing=traffic_SIGNALS. (...)

The clue-based strategy is clearly not working. There are people on this
mailing list with very strong opinions that disagree regarding the meaning
of this tag. It's easy to sympathize: we've got a tag about a *crossing*
specifying *traffic* signals, but not the exact kind of traffic
(pedestrians are also referred to as traffic) nor signal type aside from it
being lights. There is then all of this implied interpretation regarding
"controls" that always comes up but is both unstated in the wiki and
disagreed on by all.

> Problematic.  What would crossing:traffic_signals even mean other than
traffic lights with an uncontrolled pedestrian crossing.

It would mean there are signals directed at traffic for this crossing. This
is information that cannot be reliable determined from the current schema
because mappers don't know what crossing=traffic_signals means. Many
mappers think it means pedestrian-specific signals. I've met them
in-person! Regarding an "uncontrolled pedestrian crossing", keep in mind
that the wiki calls a crossing "uncontrolled" if it just has markings on
the ground, which disagrees with what uncontrolled actually means
everywhere else.

> Going by what we have at present, it's traffic lights with an
uncontrolled crossing.  Uncontrolled because nothing except common sense
tells pedestrians when to cross. (...)

In that image there are lighted signals telling pedestrians when to cross.
It's those black boxes lower on the poles.

> I don't see the markings as necessary.  They're a secondary element that
may or may not be present depending upon jurisdiction.

Then crossing=traffic_signals does not imply a marked crossing and we're
back at my previous question. You can't have both: either
crossing=traffic_signals implies marked crossings or marked crossings are
not necessary for crossing=traffic_signals. They are contradictory
statements.

If we accept that markings are not necessary for crossing=traffic_signals,
then this tag has the original fundamental problem: despite *other* values
describing markings (crossing=uncontrolled, crossing=unmarked),
traffic_signals does not. Data consumers are left without that information.
Mappers have to grapple with competing tags: do I describe traffic signals
or markings, since I can only choose one?

> I'm not opposed to being able to tag a crossing as having both lights and
markings but I don't see it as necessary (or even very useful).

Making such a decision on behalf of all pedestrians seems a bit premature.
Do all pedestrians, of all needs and preferences, share that dismissal?
Someone with a vision impairment might recognize a ladder crossing more
easily than a 20 cm light 40 meters away. Having a place where pedestrians
should be and cars should not is valuable information for a wheelchair user
(and I'd say most pedestrians). The ground markings are also considered a
right-of-way signal, depending on jurisdiction. They also improve
pedestrian safety. As a pedestrian, *I* want to know that information.

> When to halt or proceed is controlled by the lights, and those would
continue to be the controlling element even if somebody maliciously removed
the road markings.

Unless someone removes the lights or they break down and don't get fixed.
Both can be removed, I'm not sure why this is unique to the situation of
crossings.

"When to halt" is information primarily for planning trips that use street
traffic, which is the origin of this tag: estimating when cars have to
stop.

> The wiki is clear: just road markings. No lights.  No crossing guard.
Just markings.

The wiki says that uncontrolled means no traffic signals (whatever that
means - clearly there's confusion) and there are markings. It doesn't
actually say anything about lights regarding "uncontrolled". It also says
it's equivalent to an American crosswalk. Doesn't say anything about
crossing guards, because in that case it is, sensibly, a separate tag:
supervised=yes/no/*.

And you can see that the actual meaning of "uncontrolled" creeps in. The
wiki is not actually 

Re: [Tagging] Feature Proposal - crossing=marked

[Paul Allen]

On Sun, 12 May 2019 at 10:47, Tony Shield  wrote:

> Do we map the pedestrian aspects of traffic light controlled crossings?
> i.e the Walk/DontWalk or the Green/Red figures?
>
> As a pedestrian I have used many British traffic junctions controlled by
> traffic lights for the vehicles but no aspects for the pedestrian who
> has to guess and hope.
>

Traffic lights with no signal/control for pedestrians are called traffic
lights, and mapped
as highway=traffic_signals.  Traffic lights with pedestrian
signals/controls are mapped
as crossing=traffic_signals.  The distinction is already there.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Tony Shield]

Do we map the pedestrian aspects of traffic light controlled crossings? 
i.e the Walk/DontWalk or the Green/Red figures?


As a pedestrian I have used many British traffic junctions controlled by 
traffic lights for the vehicles but no aspects for the pedestrian who 
has to guess and hope.


Can we fit this element into the discussion?

TonyS999

On 11/05/2019 14:38, Martin Koppenhoefer wrote:


sent from a phone


On 11. May 2019, at 01:42, Nick Bolten  wrote:

Having trouble finding a good picture (I'll keep looking), but there are mid-block 
crossings where pedestrians can press an APS to turn on traffic warning lights - usually 
yellow in the US. Some of these crossings do not immediately give you those traffic 
warnings lights, but instead are tied to nearby traffic and turn on after a delay. When 
the lights turn on, there is some form of a pedestrian signal: sometimes the APS talks to 
you, sometimes there's a visual cue: lights turn on or a "walk" sign enables


hm, would you consider these traffic lights, or not? It basically depends on 
this interpretation whether you should use a different tag or would use 
crossing=traffic_lights
If you decide for the latter it could still make sense to add another tag for 
the specific crossing (sub)type.

Cheers, Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Martin Koppenhoefer]

sent from a phone

> On 11. May 2019, at 01:42, Nick Bolten  wrote:
> 
> Having trouble finding a good picture (I'll keep looking), but there are 
> mid-block crossings where pedestrians can press an APS to turn on traffic 
> warning lights - usually yellow in the US. Some of these crossings do not 
> immediately give you those traffic warnings lights, but instead are tied to 
> nearby traffic and turn on after a delay. When the lights turn on, there is 
> some form of a pedestrian signal: sometimes the APS talks to you, sometimes 
> there's a visual cue: lights turn on or a "walk" sign enables


hm, would you consider these traffic lights, or not? It basically depends on 
this interpretation whether you should use a different tag or would use 
crossing=traffic_lights
If you decide for the latter it could still make sense to add another tag for 
the specific crossing (sub)type.

Cheers, Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Paul Allen]

On Sat, 11 May 2019 at 01:09, Nick Bolten  wrote:

> > I would not expect to see something like that, in any of its regional
> variations (green walking person/red stationary person in much of Europe)
> without related lights controlling traffic.
>
> So, in the case of a pedestrian warning beacon, which does not control
> traffic in the cases you've mentioned, how would you tag the crossing?
> crossing=uncontrolled? Even thought it has pedestrian-facing lights *and*
> lights intended to warn traffic about pedestrians?
>

If the light is purely a warning to both traffic and pedestrians, then it's
not crossing=traffic_signals.
If it controls both traffic and pedestrians (control as in indicating
whether they should halt or
proceed) then it's crossing=traffic_signals.  Your situation of warning
lights for traffic strikes me as
bizarre and could be argued either way.  Or maybe it needs
crossing=insane_signals.


>
> There's another user in this thread who thinks the polar opposite and that
> the lights directed at traffic are irrelevant. Who is correct? What does
> the tag mean?
>

I think the clue is in the name: crossing=TRAFFIC_signals.  Also
CROSSING=traffic_signals.  And
crossing=traffic_SIGNALS.  It is a crossing for pedestrians which has
signals for the traffic.  Of
course, going by the name alone you could argue there are signals for
traffic but not for pedestrians
but that is handled as traffic lights plus crossing=uncontrolled.


> This is making me think that my other proposal should be revised so as to
> separate out pedestrian signals from street traffic signals entirely.
> Something like crossing:pedestrian_signals=yes/no/(type) and
> crossing:traffic_signals=yes/no/(type)
>

Problematic.  What would crossing:traffic_signals even mean other than
traffic lights with an
uncontrolled pedestrian crossing.

>
> > Not necessarily.  Most countries there probably is something, if only
> tactile paving for the blind.
>
> I think I miscommunicated - I'm referring to that intersection in the
> picture only, where the crossings are marked with the ladder pattern.
>

Going by what we have at present, it's traffic lights with an uncontrolled
crossing.  Uncontrolled
because nothing except common sense tells pedestrians when to cross.  There
are no lights
telling them when they can and cannot cross.  There is no crossing guard.
It's just a place
where crossing is legal (in the US it may be illegal to cross where there
are no markings; in
the UK it's legal to cross without markings) and there also happen to be
traffic lights
controlling traffic alone.

Earlier, the necessary conditions for crossing=traffic_signals were solely
> (1) signals that control pedestrians and (2) signals that control street
> traffic. But now, at this intersection, crossing=traffic_signals implies
> markings? This is a contradiction. It is simply not possible for both to be
> true. So you can see my dilemma in trying to use such a tag.
>

I don't see the markings as necessary.  They're a secondary element that
may or may not be
present depending upon jurisdiction.  At most they're a warning that there
are traffic signals
controlling a crossing, a warning for people looking down at the road who
might otherwise not
notice the lights.  When to halt or proceed is controlled by the lights,
and those would
continue to be the controlling element even if somebody maliciously removed
the road markings.

Keep in mind, all I want to describe is whether a crossing has markings and
> whether it has pedestrian signals. That seems like something just about any
> person on the street should be able to answer, but the schema makes it
> difficult to tag.
>

I'm not opposed to being able to tag a crossing as having both lights and
markings but I don't
see it as necessary (or even very useful).  There are crossings that are
only markings and there
are crossings that are controlled by lights.


>
> > I would say that both pedestrians and traffic have to be controlled.
> Controlled pedestrians and
> uncontrolled traffic is insane.  Controlled traffic and uncontrolled
> pedestrians is traffic lights.
>
> Not according to most definitions of "controlled", in terms of traffic
> lights. A stop sign is a form of traffic control. Also, someone in the
> other thread claimed that dropped curbs were a control. Someone in this
> thread says a marked crossing is a control. Nobody agrees on what a control
> is in OpenStreetMap, so how can we ever trust data for "uncontrolled"? I'd
> guess that almost nobody is using it for anything other than a delay on a
> router (car might have to stop) or some generic visualizations of feature
> density. They can't, not reliably.
>

The wiki is clear: just road markings. No lights.  No crossing guard.  Just
markings.

>
> > The pedestrian-facing lights and vehicle-facing lights don't even have
> to be on the same pole, but they should be positioned such as to control
> the pedestrians and traffic at a crossing and be operated in 

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

> I'd still classify that as crossing=traffic_signals.

Ah, now I'm super confused. I would've sworn that you'd recommend mapping
that as uncontrolled.

> The real world is too messy.  Can we map a fictional world instead?

People actually love doing that:
https://www.pcinvasion.com/wp-content/uploads/2016/03/cities-skylines-canal.jpg

I'd like to harness those people by writing some accessible mapping apps
and get good pedestrian tags, but I don't want to add bad crossing tags...



On Fri, May 10, 2019 at 5:02 PM Paul Allen  wrote:

> On Sat, 11 May 2019 at 00:44, Nick Bolten  wrote:
>
>> Having trouble finding a good picture (I'll keep looking), but there are
>> mid-block crossings where pedestrians can press an APS to turn on traffic
>> warning lights - usually yellow in the US. Some of these crossings do not
>> immediately give you those traffic warnings lights, but instead are tied to
>> nearby traffic and turn on after a delay. When the lights turn on, there is
>> some form of a pedestrian signal: sometimes the APS talks to you, sometimes
>> there's a visual cue: lights turn on or a "walk" sign enables.
>>
>
> Ugh!
>
> I'd still classify that as crossing=traffic_signals.  Because as well as
> controlling pedestrians it
> does signal to traffic.  An advisory signal rather than a controlling
> signal, but still a signal.  That's
> not like the Belisha Beacon on a Zebra that flashes whether or not there
> are any pedestrians
> there.
>
> That's not quite like the flashing amber signal near school crossings
> which are supervised by
> a crossing guard: the guard turns them on at the start of the shift and
> turns them off at the
> end of the shift, there may be nobody crossing from the time the driver
> sees them to the time
> the driver has cleared the crossing.  I can see an argument for including
> those if we include yours,
> but I doubt many people in the UK think of them as traffic lights.
>
> The real world is too messy.  Can we map a fictional world instead?
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Paul Allen]

On Sat, 11 May 2019 at 00:44, Nick Bolten  wrote:

> Having trouble finding a good picture (I'll keep looking), but there are
> mid-block crossings where pedestrians can press an APS to turn on traffic
> warning lights - usually yellow in the US. Some of these crossings do not
> immediately give you those traffic warnings lights, but instead are tied to
> nearby traffic and turn on after a delay. When the lights turn on, there is
> some form of a pedestrian signal: sometimes the APS talks to you, sometimes
> there's a visual cue: lights turn on or a "walk" sign enables.
>

Ugh!

I'd still classify that as crossing=traffic_signals.  Because as well as
controlling pedestrians it
does signal to traffic.  An advisory signal rather than a controlling
signal, but still a signal.  That's
not like the Belisha Beacon on a Zebra that flashes whether or not there
are any pedestrians
there.

That's not quite like the flashing amber signal near school crossings which
are supervised by
a crossing guard: the guard turns them on at the start of the shift and
turns them off at the
end of the shift, there may be nobody crossing from the time the driver
sees them to the time
the driver has cleared the crossing.  I can see an argument for including
those if we include yours,
but I doubt many people in the UK think of them as traffic lights.

The real world is too messy.  Can we map a fictional world instead?

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

> I would not expect to see something like that, in any of its regional
variations (green walking person/red stationary person in much of Europe)
without related lights controlling traffic.

So, in the case of a pedestrian warning beacon, which does not control
traffic in the cases you've mentioned, how would you tag the crossing?
crossing=uncontrolled? Even thought it has pedestrian-facing lights *and*
lights intended to warn traffic about pedestrians?

There's another user in this thread who thinks the polar opposite and that
the lights directed at traffic are irrelevant. Who is correct? What does
the tag mean?

This is making me think that my other proposal should be revised so as to
separate out pedestrian signals from street traffic signals entirely.
Something like crossing:pedestrian_signals=yes/no/(type) and
crossing:traffic_signals=yes/no/(type)

> Not necessarily.  Most countries there probably is something, if only
tactile paving for the blind.

I think I miscommunicated - I'm referring to that intersection in the
picture only, where the crossings are marked with the ladder pattern.

>> If we tag that as crossing=traffic_signals, have we correctly and
consistently communicated all of that information?
> Maybe.  People are capable of misinterpreting anything.

Of course, but that's the same regardless of whether a tagging schema is
awful or ideal.

Earlier, the necessary conditions for crossing=traffic_signals were solely
(1) signals that control pedestrians and (2) signals that control street
traffic. But now, at this intersection, crossing=traffic_signals implies
markings? This is a contradiction. It is simply not possible for both to be
true. So you can see my dilemma in trying to use such a tag.

Keep in mind, all I want to describe is whether a crossing has markings and
whether it has pedestrian signals. That seems like something just about any
person on the street should be able to answer, but the schema makes it
difficult to tag.

> I would say that both pedestrians and traffic have to be controlled.
Controlled pedestrians and
uncontrolled traffic is insane.  Controlled traffic and uncontrolled
pedestrians is traffic lights.

Not according to most definitions of "controlled", in terms of traffic
lights. A stop sign is a form of traffic control. Also, someone in the
other thread claimed that dropped curbs were a control. Someone in this
thread says a marked crossing is a control. Nobody agrees on what a control
is in OpenStreetMap, so how can we ever trust data for "uncontrolled"? I'd
guess that almost nobody is using it for anything other than a delay on a
router (car might have to stop) or some generic visualizations of feature
density. They can't, not reliably.

> The pedestrian-facing lights and vehicle-facing lights don't even have to
be on the same pole, but they should be positioned such as to control the
pedestrians and traffic at a crossing and be operated in synchrony by the
same controller.  Together they constitute a single crossing.

I wholeheartedly disagree. A crossing is not the signals. A crossing is
where pedestrians cross the street. A crossing can *have* signalization:
signals are a property of a crossing. This is similar to how a crossing is
not an island and why crossing=island was a bad idea.

> Oh, and you can have two independent crossings within a few yards of each
other which handle one direction of traffic flow on a road with several
lanes (...)

As footways, I would map this as three elements: all are footway=crossing,
the central island is crossing:island=yes, the other two are... well, I
don't know, really. That's what I'm asking questions about. Maybe
crossing=traffic_signals.

On Fri, May 10, 2019 at 4:31 PM Paul Allen  wrote:

> On Fri, 10 May 2019 at 23:59, Nick Bolten  wrote:
>
>> >> - A crossing might be marked on the ground
>>
>> > Are there traffic signals which control BOTH traffic and pedestrians?
>> If so,
>> > crossing=traffic_signals.   If there are JUST road markings, no
>> crossing=traffic_signals.
>>
>> I interpret this to mean: the necessary condition for using
>> crossing=traffic_signals is that there are signals controlling both traffic
>> and pedestrians. If only one or the other, it is not a
>> crossing=traffic_signals.
>>
>
> That's how I intended it.  If it only controls traffic then it's ordinary
> traffic lights (regardless of
> whether people use it as a place to cross).  If it only controls
> pedestrians it's insane: "Yep,
> you can cross now, don't worry about those cars because there's nothing I
> can do to stop
> them."
>
>
> >> - A crossing might have lighted signals for pedestrians to cross
>>
>> > Define what you mean by lighted signals.  If you mean a Belisha Beacon
>> or something else that WARNS motorists that pedestrians cross here but does
>> NOT control traffic and pedestrians then it's not
>> crossing=traffic_signals.  A warning light is not a traffic signal.
>>
>> In this case, I was thinking of a specific "walk/do not 

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

> you have still to show us a crossing with traffic lights only for
pedestrians :)

Having trouble finding a good picture (I'll keep looking), but there are
mid-block crossings where pedestrians can press an APS to turn on traffic
warning lights - usually yellow in the US. Some of these crossings do not
immediately give you those traffic warnings lights, but instead are tied to
nearby traffic and turn on after a delay. When the lights turn on, there is
some form of a pedestrian signal: sometimes the APS talks to you, sometimes
there's a visual cue: lights turn on or a "walk" sign enables.

Whether warning lights count as a "traffic signal" seems to be an issue of
contention. There's a theme!

> Crossing refers to a pedestrian (or bicycle) crossing, when there are
only traffic lights for the traffic on the road, but not for the crossing
traffic then there won’t be a crossing tag.

I think I'm confused. crossing=unmarked and crossing=uncontrolled would
both apply in that situation, right?

On Fri, May 10, 2019 at 4:24 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 11. May 2019, at 00:57, Nick Bolten  wrote:
> >
> > If only one or the other, it is not a crossing=traffic_signals.
>
>
> you have still to show us a crossing with traffic lights only for
> pedestrians :)
>
> Crossing refers to a pedestrian (or bicycle) crossing, when there are only
> traffic lights for the traffic on the road, but not for the crossing
> traffic then there won’t be a crossing tag.
>
>
> Cheers, Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

> If you search traffic light you will see the same thing, not any strange
light in relation with traffic itself.
https://www.google.com/search?q=traffic+light=lnms=isch=X=0ahUKEwj3vf-XqJHiAhWhzoUKHYr5D3kQ_AUIDigB=1280=891
> (...)
> There is no ambiguosity: point is where is the feature, where the feature
acts.

Per Paul's explanation, crossing=traffic_signals implies two traffic
lights: one for pedestrians, one for traffic. So it's not actually solely
oriented towards the feature.

If you disagree with Paul's definition, that would not be uncommon: nobody
seems to agree on what crossing=traffic_signals or crossing=uncontrolled
means.

> Why you suppose marked is better than uncontrolled? (...)

I have explained it in the wiki, but am happy to expand on the proposal if
you think it does an inadequate job.

I'm skipping a few of your replies because I believe I can address them in
the other sections. Please remind me if you feel I've ignored something
entirely.

> Tagging schemes with yes/no binary values makes more complex the
scheme... (...)

While this proposal currently states a binary (yes/no), I'm open to having
more values. The goal is for the crossing tag to have values that are all
in the same category, because right now they describe several different
things incompletely. This is in addition to being poorly understood by just
about everyone. Because the vast majority of existing crossing tags are
regarding markings, I thought this would be the natural "primary" value.

Imagine you were writing a software application that asked a pedestrian one
or more questions about a crossing. Behind the scenes, you edit
OpenStreetMap to add a crossing=* tag. Think something like StreetComplete,
which is a very cool app. What questions do you ask? It's a hard problem to
solve because the tag values are *bad*.

> That is a traffic light for pedestrian. Why do you want any mark if you
have a traffic light to control it? In my country...that situation does not
exist.

The situation exists in my country, so how do you map it? What tags?

> That is crossing=uncontrolled, because there is no control about the
footway crossing.

Stop signs are a control, but they're for street traffic.

> Well , it is crossing=unmarked because there is no marks on the corssing
(...)

The stop sign is related to the crossing, as it indicates that traffic has
to stop there. Depending on the country, this has right-of-way implications
- the exact same ones where the term "uncontrolled" comes from.

> Well, it will be a crossing=unmarked, because there is no mark on the
ground (...)

In my area, that is a valid place to cross and pedestrians have the
right-of-way.

> WTF? For what do you need walk/don't walk parameter if there is no
traffic light with???

A mid-block crossing that has pedestrian signals and only warning lights
for cars. Other mappers have told me that warning signals are not traffic
lights, per the definition of crossing=traffic_signals.

> Are you sure an administration will put an only car traffic light...with
a pedestrian crossing in but with no pedestrian traffic light? How bizarre
the world is.

I'm describing a crossing like this:
https://www.colchestervt.gov/ImageRepository/Document?documentID=185. There
are marked crossings on the ground.

> Is there any unsyncronized crossing with the same traffic lights inside
the crossing? Which drunken monkey design these crossings? How many people
die in ?

I'm describing the situation in the picture above but with no ground
markings.

> Error: Pedestrian has ALWAYS the right of way in a crossing with marks of
crossings (crossing=uncontrolled if there is no traffic_signal)

In every country on earth? In all situations that lack a signal?

> No. Control is something that sometimes says you if you are allowed or
not to cross. A dropped curb says you always the same: nothing.

So you disagree with the other mappers who said as much on this mailing
list. That's my point: nobody seems to agree on what these tags mean.

Best,

Nick


On Fri, May 10, 2019 at 2:20 PM yo paseopor  wrote:

> No, don't be innocent
>
> If you search traffic light you will see the same thing, not any strange
> light in relation with traffic itself.
>
> https://www.google.com/search?q=traffic+light=lnms=isch=X=0ahUKEwj3vf-XqJHiAhWhzoUKHYr5D3kQ_AUIDigB=1280=891
> https://en.wikipedia.org/wiki/Traffic_light.
> If you make a specific micromapping you will not have problems. Otherwise
> you can't ask for detailed information if the mapping is not as detailed.
>
> If you see a traffic light in a footway is for the footway, not the
> highway.
> If you see a traffic light in a cycleway is for the cycleway, not the
> highway.
>
> There is no ambiguosity: point is where is the feature, where the feature
> acts.
>
> Why you suppose marked is better than uncontrolled? Do you suppose that
> new mapper doesn't know for which kind of marks are you talk about? Marked
> with? Traffic sign? Traffic light? other lights in 

Re: [Tagging] Feature Proposal - crossing=marked

[Paul Allen]

On Fri, 10 May 2019 at 23:59, Nick Bolten  wrote:

> >> - A crossing might be marked on the ground
>
> > Are there traffic signals which control BOTH traffic and pedestrians?
> If so,
> > crossing=traffic_signals.   If there are JUST road markings, no
> crossing=traffic_signals.
>
> I interpret this to mean: the necessary condition for using
> crossing=traffic_signals is that there are signals controlling both traffic
> and pedestrians. If only one or the other, it is not a
> crossing=traffic_signals.
>

That's how I intended it.  If it only controls traffic then it's ordinary
traffic lights (regardless of
whether people use it as a place to cross).  If it only controls
pedestrians it's insane: "Yep,
you can cross now, don't worry about those cars because there's nothing I
can do to stop
them."


>> - A crossing might have lighted signals for pedestrians to cross
>
> > Define what you mean by lighted signals.  If you mean a Belisha Beacon
> or something else that WARNS motorists that pedestrians cross here but does
> NOT control traffic and pedestrians then it's not
> crossing=traffic_signals.  A warning light is not a traffic signal.
>
> In this case, I was thinking of a specific "walk/do not walk" lighted
> signal.
>

I would not expect to see something like that, in any of its regional
variations (green walking
person/red stationary person in much of Europe) without related lights
controlling traffic.

>
> > That's crossing=traffic_signals IF it also controls pedestrians.
> Walk/Don't Walk ot Red/Green figures or whatever.  Otherwise it's just
> traffic lights.  Even if people can cross there, it's still just traffic
> lights because the crossing (by people) Isn't controlled, just the traffic
> is.  Traffic has to stop when the lights tell them, the pedestrians take
> their chances and are uncontrolled.
>
> I take this to mean that the signals do not need to be colocated in order
> to tag crossing=traffic_signals, such as in this scenario:
> https://www.colchestervt.gov/ImageRepository/Document?documentID=185.
>
> - There are markings on the ground
>

Not necessarily.  Most countries there probably is something, if only
tactile paving for the blind.

- There are pedestrian-facing signals
> - There are traffic signals at the intersection controlling traffic
>

Those are the two important bits.  Along with the fact that they are
operated by a single
controller.  No point to them if they operate independently.  The whole
idea is that they stop
traffic to let pedestrians cross and stop pedestrians to let traffic flow.

There may be a button that pedestrians can press to signal their presence.
In some countries,
in some cases, that button is a dummy.  A light comes on to tell you that
you've pressed it but it
has no influence upon the timing cycle.  The timing cycle may be controlled
by road sensors,
or by time of day, or may have a fixed duration.  Presence or absence of a
button is irrelevant.


> If we tag that as crossing=traffic_signals, have we correctly and
> consistently communicated all of that information?
>

Maybe.  People are capable of misinterpreting anything.

>
> As an aside regarding the term "controlled", the OSM wiki doesn't actually
> say any of this about whether it's traffic or pedestrians or both being
> controlled. What it actually states is that crossing=uncontrolled is
> equivalent to a marked crossing or "crosswalk". A marked crossing can have
> or lack all forms of traffic signals that we've discussed.
>

I would say that both pedestrians and traffic have to be controlled.
Controlled pedestrians and
uncontrolled traffic is insane.  Controlled traffic and uncontrolled
pedestrians is traffic lights.

> *Sigh*  Was all this about pedantry?  The same interlocked mechanism
> controls two sets of lights on the same pole, one set controls vehicular
> traffic the other set controls pedestrians.  I didn't mean that both
> pedestrians and motorists stare at exactly the same set of lights.
>
> That's not pedantry, it's the precision that we need to describe
> crossings. Are we mapping based on lights or a connected signal apparatus?
> That's an actually important question. We should be able to say that
> clearly to new mappers and embed it into mapping tools.
>

The pedestrian-facing lights and vehicle-facing lights don't even have to
be on the same pole,
but they should be positioned such as to control the pedestrians and
traffic at a crossing and
be operated in synchrony by the same controller.  Together they constitute
a single crossing.

Yes, you're going to have to spell out all the variants.  Like the image
you linked to where lights are
suspended from cables in the middle of the road and only face traffic, but
they're part of the same
single crossing.  Traffic-facing and pedestrian-facing lights for the same
crossing might be on
different poles.

Oh, and you can have two independent crossings within a few yards of each
other which handle
one direction of traffic flow on a road with 

Re: [Tagging] Feature Proposal - crossing=marked

[Martin Koppenhoefer]

sent from a phone

> On 11. May 2019, at 00:57, Nick Bolten  wrote:
> 
> If only one or the other, it is not a crossing=traffic_signals.


you have still to show us a crossing with traffic lights only for pedestrians :)

Crossing refers to a pedestrian (or bicycle) crossing, when there are only 
traffic lights for the traffic on the road, but not for the crossing traffic 
then there won’t be a crossing tag.


Cheers, Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

>> - A crossing might be marked on the ground

> Are there traffic signals which control BOTH traffic and pedestrians?  If
so,
> crossing=traffic_signals.   If there are JUST road markings, no
crossing=traffic_signals.

I interpret this to mean: the necessary condition for using
crossing=traffic_signals is that there are signals controlling both traffic
and pedestrians. If only one or the other, it is not a
crossing=traffic_signals.

>> - A crossing might have lighted signals for pedestrians to cross

> Define what you mean by lighted signals.  If you mean a Belisha Beacon or
something else that WARNS motorists that pedestrians cross here but does
NOT control traffic and pedestrians then it's not
crossing=traffic_signals.  A warning light is not a traffic signal.

In this case, I was thinking of a specific "walk/do not walk" lighted
signal.

>> - A crossing might be protected by a traffic light that tells traffic to
stop. That light might be at the crossing or at a street intersection.

> That's crossing=traffic_signals IF it also controls pedestrians.
Walk/Don't Walk ot Red/Green figures or whatever.  Otherwise it's just
traffic lights.  Even if people can cross there, it's still just traffic
lights because the crossing (by people) Isn't controlled, just the traffic
is.  Traffic has to stop when the lights tell them, the pedestrians take
their chances and are uncontrolled.

I take this to mean that the signals do not need to be colocated in order
to tag crossing=traffic_signals, such as in this scenario:
https://www.colchestervt.gov/ImageRepository/Document?documentID=185.

- There are markings on the ground
- There are pedestrian-facing signals
- There are traffic signals at the intersection controlling traffic

If we tag that as crossing=traffic_signals, have we correctly and
consistently communicated all of that information?

As an aside regarding the term "controlled", the OSM wiki doesn't actually
say any of this about whether it's traffic or pedestrians or both being
controlled. What it actually states is that crossing=uncontrolled is
equivalent to a marked crossing or "crosswalk". A marked crossing can have
or lack all forms of traffic signals that we've discussed.

>>> In any sane world, lights to control pedestrians also function as
lights to control traffic.

>> Then we live in an insane world! I'm not aware of any lights that
control both pedestrians and traffic - they are oriented in orthogonal
directions.

> *Sigh*  Was all this about pedantry?  The same interlocked mechanism
controls two sets of lights on the same pole, one set controls vehicular
traffic the other set controls pedestrians.  I didn't mean that both
pedestrians and motorists stare at exactly the same set of lights.

That's not pedantry, it's the precision that we need to describe crossings.
Are we mapping based on lights or a connected signal apparatus? That's an
actually important question. We should be able to say that clearly to new
mappers and embed it into mapping tools.

> I don't think we can let occasional errors by novice mappers define tags
for us.  If such errors are widespread then we need to introduce a
replacement scheme, encourage it for new use and manually replace the old
scheme.

Given that I've received a different definition of the term "uncontrolled"
from every response in this and the other proposal thread, I do not suspect
this is an issue that is occasional nor restricted to new mappers.

On Fri, May 10, 2019 at 1:20 PM Paul Allen  wrote:

> On Fri, 10 May 2019 at 21:03, Nick Bolten  wrote:
>
>> I still don't know when you think we should use
>> crossing=traffic_signals...
>>
>> - A crossing might be marked on the ground
>>
>
> Are there traffic signals which control BOTH traffic and pedestrians?  If
> so,
> crossing=traffic_signals.   If there are JUST road markings, no
> crossing=traffic_signals.
>
> - A crossing might have lighted signals for pedestrians to cross
>>
>
> Define what you mean by lighted signals.  If you mean a Belisha Beacon or
> something else that
> WARNS motorists that pedestrians cross here but does NOT control traffic
> and pedestrians
> then it's not crossing=traffic_signals.  A warning light is not a traffic
> signal.
>
> - A crossing might be protected by a traffic light that tells traffic to
>> stop. That light might be at the crossing or at a street intersection.
>>
>
> That's crossing=traffic_signals IF it also controls pedestrians.
> Walk/Don't Walk ot Red/Green
> figures or whatever.  Otherwise it's just traffic lights.  Even if people
> can cross there, it's still
> just traffic lights because the crossing (by people) Isn't controlled,
> just the traffic is.  Traffic has
> to stop when the lights tell them, the pedestrians take their chances and
> are uncontrolled.
>
> - A crossing might be protected by warning lights to raise pedestrian
>> visibility
>>
>
> Not crossing=traffic_lights.  Traffic lights control traffic, at a
> minimum.  If they also control
> pedestrians 

Re: [Tagging] Feature Proposal - crossing=marked

[Martin Koppenhoefer]

sent from a phone

> On 10. May 2019, at 23:17, yo paseopor  wrote:
> 
> A mark is not a control. A sign is not a control (when yes, when no)


signs and markings are commonly considered traffic controls.

Cheers, Martin 



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[yo paseopor]

No, don't be innocent

If you search traffic light you will see the same thing, not any strange
light in relation with traffic itself.
https://www.google.com/search?q=traffic+light=lnms=isch=X=0ahUKEwj3vf-XqJHiAhWhzoUKHYr5D3kQ_AUIDigB=1280=891
https://en.wikipedia.org/wiki/Traffic_light.
If you make a specific micromapping you will not have problems. Otherwise
you can't ask for detailed information if the mapping is not as detailed.

If you see a traffic light in a footway is for the footway, not the highway.
If you see a traffic light in a cycleway is for the cycleway, not the
highway.

There is no ambiguosity: point is where is the feature, where the feature
acts.

Why you suppose marked is better than uncontrolled? Do you suppose that new
mapper doesn't know for which kind of marks are you talk about? Marked
with? Traffic sign? Traffic light? other lights in the traffic?

Crossing tag scheme is based ...on the marks and other items you will have:
traffic_signals, supervised=yes, uncontrolled (but marked), unmarked, no
(prohibited). If you put a crossing=marked...what do you mean? , which of
them do will you substitute?

Uncontrolled means NO CONTROL. A mark is not a control. A sign is not a
control (when yes, when no). Supervised means with supervision, traffic
signals with traffic light. Unmarked...what do you expect about control if
there is not any mark.

You had said " As someone who has personally mapped thousands of crossings,
the current schema is absolute garbage for reliably collecting accurate
data that can be reliably interpreted by data consumers that aren't solely
focused on car routing."
No, if the crossing is in a footway  you will have info about the footway,
not only for cars. In Openstreetmap there is a lot of tagging schemes who
thinks far away from cars only: kerbs, sidewalks, wheelchair...Use it also,
not only crossings.

> The iD editor never uses crossing=uncontrolled. It actually uses
crossing=marked now.
Well, I think it is a big error, because there is no marked values at the
wiki and you have the same thing with the value uncontrolled in the wiki.

>I anticipate that many US-based communities would be open to converting
crossing=uncontrolled and crossing=zebra to crossing=marked, at a minimum,
given how frequently they've been edited with iD.
I don't why US-based communities would not be open to converting
crossing=zebra (which does not exists, is crossing_ref= if you read the
wiki) to crossing=uncontrolled that is the value you can read in the wiki
instead of mix values and tags to create a new scheme.

>A controlled crossing can have or lack ground markings, and an
uncontrolled can have or lack ground markings.
Yes, but it has no-sense . Why control one thing that you don't indicate by
any way. First make it visible, then control it.

> In your country, how do you map a crossing that has traffic controls but
does not have markings on the ground?
It does not exists and I have to say I don't remember see this in the rest
of Europe I have visited.

Tagging schemes with yes/no binary values makes more complex the
scheme...yes there is only two possible values...but then you have to have
three different tags for the same thing.Yes, the scheme you are proposing
here will have more descriptional tags...but also have three more time tags
than the existing one with the same information.

> Map a crossing that is unmarked and has pedestrian signals ("walk"/"do
not walk").
That is a traffic light for pedestrian. Why do you want any mark if you
have a traffic light to control it? In my country...that situation does not
exist.

> Map a crossing that is marked and is protected by a stop sign but no
traffic light, then say how you would interpret this as a data consumer.
That is crossing=uncontrolled, because there is no control about the
footway crossing.

> Map a crossing that is unmarked and is protected by a stop sign but no
traffic light, then say how you would interpret this as a data consumer.
Well , it is crossing=unmarked because there is no marks on the corssing. A
stop sign is about the highway cross with other way, nothing to have
relation with a pedestrian crossing, otherwise you will have other kind of
traffic sign, not Stop.

> Map a crossing that is unmarked and is protected by its own,
non-street-intersection traffic light, then say how you would interpret
this as a data consumer.
Well, it will be a crossing=unmarked, because there is no mark on the
ground, also I say in my country you have avoided to cross by there except
in residential streets (the one's with the same level on sidewalk and the
road itself )

> Map a crossing that is unmarked, has pedestrian-specific signals
("walk"/"do not walk"), but no traffic signals at all nearby.
WTF? For what do you need walk/don't walk parameter if there is no traffic
light with???

> Map a crossing that has markings and is protected by a traffic light, but
that traffic light is part of the overall highway=traffic_signals

Re: [Tagging] Feature Proposal - crossing=marked

[Paul Allen]

On Fri, 10 May 2019 at 21:03, Nick Bolten  wrote:

> I still don't know when you think we should use crossing=traffic_signals...
>
> - A crossing might be marked on the ground
>

Are there traffic signals which control BOTH traffic and pedestrians?  If
so,
crossing=traffic_signals.   If there are JUST road markings, no
crossing=traffic_signals.

- A crossing might have lighted signals for pedestrians to cross
>

Define what you mean by lighted signals.  If you mean a Belisha Beacon or
something else that
WARNS motorists that pedestrians cross here but does NOT control traffic
and pedestrians
then it's not crossing=traffic_signals.  A warning light is not a traffic
signal.

- A crossing might be protected by a traffic light that tells traffic to
> stop. That light might be at the crossing or at a street intersection.
>

That's crossing=traffic_signals IF it also controls pedestrians.
Walk/Don't Walk ot Red/Green
figures or whatever.  Otherwise it's just traffic lights.  Even if people
can cross there, it's still
just traffic lights because the crossing (by people) Isn't controlled, just
the traffic is.  Traffic has
to stop when the lights tell them, the pedestrians take their chances and
are uncontrolled.

- A crossing might be protected by warning lights to raise pedestrian
> visibility
>

Not crossing=traffic_lights.  Traffic lights control traffic, at a
minimum.  If they also control
pedestrians then they're crossing=traffic_lights.  If they just warn
motorists they're not
traffic lights of any kind.

>
> Which part(s) of that does crossing=traffic_signals describe?
>

See above.  Just my own opinion, of course.

>
> > In any sane world, lights to control pedestrians also function as lights
> to control traffic.
>
> Then we live in an insane world! I'm not aware of any lights that control
> both pedestrians and traffic - they are oriented in orthogonal directions.
>

*Sigh*  Was all this about pedantry?  The same interlocked mechanism
controls two sets of lights
on the same pole, one set controls vehicular traffic the other set controls
pedestrians.  I didn't
mean that both pedestrians and motorists stare at exactly the same set of
lights.

Similar to you, I have yet to find an intersection with a pedestrian signal
> that does not have some form of either warning or explicit traffic control
> (but it could be either one), but I wouldn't rule it out based on my
> experience alone. However, the existence of a traffic light doesn't imply
> any other infrastructure: the crossing might lack pedestrian signals, its
> own dedicated light near the crossing, and even any particular visual
> markings indicating where to cross. Despite this, the
> crossing=traffic_signals tag has been used to describe all of these things,
> somehow.
>

I don't think we can let occasional errors by novice mappers define tags
for us.  If such errors are
widespread then we need to introduce a replacement scheme, encourage it for
new use and
manually replace the old scheme.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

I still don't know when you think we should use crossing=traffic_signals...

Imagine you're outside the UK. Pelican signals don't exist. No animal
signals, mythical or real, of any kind. There's just infrastructure:

- A crossing might be marked on the ground
- A crossing might have lighted signals for pedestrians to cross
- A crossing might be protected by a traffic light that tells traffic to
stop. That light might be at the crossing or at a street intersection.
- A crossing might be protected by warning lights to raise pedestrian
visibility

Which part(s) of that does crossing=traffic_signals describe?

> In any sane world, lights to control pedestrians also function as lights
to control traffic.

Then we live in an insane world! I'm not aware of any lights that control
both pedestrians and traffic - they are oriented in orthogonal directions.

> I can't see any sensible use case for lights that tell pedestrians they
can cross that do not also control traffic.  In the UK these usually
(always) look identical to "ordinary" traffic lights with the operational
exception of a protracted flashing amber to let pedestrians finish
crossing. From a motorist's perspective they are indistinguishable (at
first glance) from "ordinary" traffic lights.

Similar to you, I have yet to find an intersection with a pedestrian signal
that does not have some form of either warning or explicit traffic control
(but it could be either one), but I wouldn't rule it out based on my
experience alone. However, the existence of a traffic light doesn't imply
any other infrastructure: the crossing might lack pedestrian signals, its
own dedicated light near the crossing, and even any particular visual
markings indicating where to cross. Despite this, the
crossing=traffic_signals tag has been used to describe all of these things,
somehow.

On Fri, May 10, 2019 at 12:31 PM Paul Allen  wrote:

> On Fri, 10 May 2019 at 19:27, Nick Bolten  wrote:
>
>> This all makes sense, but the question is: what does
>> crossing=traffic_lights mean given these contexts? There are at least 3
>> types of lights and I've seen all of them referred to as "traffic lights",
>> even on UK government websites:
>>
>> - Pedestrian signals, i.e. "walk/do not walk" lights of any kind meant to
>> indicate that pedestrians should cross.
>>
>
> In any sane world, lights to control pedestrians also function as lights
> to control traffic.  I can't
> see any sensible use case for lights that tell pedestrians they can cross
> that do not also
> control traffic.  In the UK these usually (always) look identical to
> "ordinary" traffic lights with
> the operational exception of a protracted flashing amber to let
> pedestrians finish crossing.
> From a motorist's perspective they are indistinguishable (at first glance)
> from "ordinary"
> traffic lights.
>
> - The traffic lights for street traffic that are specifically associated
>> with a pedestrian crossing, as in the pelican example - the traffic light
>> pole also has all of these things: a pedestrian signal, a light for street
>> traffic (stop/go/etc), and there is generally an APS to request a crossing
>> signal.
>>
>
> This, rather than your first case, is all I've ever seen in the UK.
>
> - The traffic lights for street traffic that are not explicitly associated
>> with a particular crossing. The crossing is still protected by those
>> lights, there might even be an APS, but the traffic light is located at
>> highway=traffic_signals, i.e. the center of a street intersection.
>>
>
> If they ARE intended as a crossing then, in the UK, they'll be a pelican
> again, even if they're also
> controlling an intersection.  Not to be confused with ordinary traffic
> lights at an intersection which
> may not be intended for use as a crossing but tend to be used that way
> (because the traffic in
> one direction has been stopped, making crossing perhaps a little less
> difficult).
>
> As far as I can tell (at least in the UK) it boils down to either traffic
> lights that have nothing to do
> with pedestrians or traffic lights that also control pedestrians.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Paul Allen]

On Fri, 10 May 2019 at 19:27, Nick Bolten  wrote:

> This all makes sense, but the question is: what does
> crossing=traffic_lights mean given these contexts? There are at least 3
> types of lights and I've seen all of them referred to as "traffic lights",
> even on UK government websites:
>
> - Pedestrian signals, i.e. "walk/do not walk" lights of any kind meant to
> indicate that pedestrians should cross.
>

In any sane world, lights to control pedestrians also function as lights to
control traffic.  I can't
see any sensible use case for lights that tell pedestrians they can cross
that do not also
control traffic.  In the UK these usually (always) look identical to
"ordinary" traffic lights with
the operational exception of a protracted flashing amber to let pedestrians
finish crossing.
>From a motorist's perspective they are indistinguishable (at first glance)
from "ordinary"
traffic lights.

- The traffic lights for street traffic that are specifically associated
> with a pedestrian crossing, as in the pelican example - the traffic light
> pole also has all of these things: a pedestrian signal, a light for street
> traffic (stop/go/etc), and there is generally an APS to request a crossing
> signal.
>

This, rather than your first case, is all I've ever seen in the UK.

- The traffic lights for street traffic that are not explicitly associated
> with a particular crossing. The crossing is still protected by those
> lights, there might even be an APS, but the traffic light is located at
> highway=traffic_signals, i.e. the center of a street intersection.
>

If they ARE intended as a crossing then, in the UK, they'll be a pelican
again, even if they're also
controlling an intersection.  Not to be confused with ordinary traffic
lights at an intersection which
may not be intended for use as a crossing but tend to be used that way
(because the traffic in
one direction has been stopped, making crossing perhaps a little less
difficult).

As far as I can tell (at least in the UK) it boils down to either traffic
lights that have nothing to do
with pedestrians or traffic lights that also control pedestrians.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

This all makes sense, but the question is: what does
crossing=traffic_lights mean given these contexts? There are at least 3
types of lights and I've seen all of them referred to as "traffic lights",
even on UK government websites:

- Pedestrian signals, i.e. "walk/do not walk" lights of any kind meant to
indicate that pedestrians should cross.
- The traffic lights for street traffic that are specifically associated
with a pedestrian crossing, as in the pelican example - the traffic light
pole also has all of these things: a pedestrian signal, a light for street
traffic (stop/go/etc), and there is generally an APS to request a crossing
signal.
- The traffic lights for street traffic that are not explicitly associated
with a particular crossing. The crossing is still protected by those
lights, there might even be an APS, but the traffic light is located at
highway=traffic_signals, i.e. the center of a street intersection.

The OSM wiki describes crossing=traffic_signals as, "Position this tag
where the crossing-traffic (pedestrian, bicycles) have their own traffic
lights." I still have no idea which of these things that is meant to apply
to. I wouldn't personally consider a intersection-centered traffic light to
be pedestirans' "own" traffic lights, but they have roughly the same
function and impact on pedestrian needs as a pelican crossing, in terms of
traffic. I've been told a few times, on this mailing list, that it does not
apply to pedestrian signals, but that's hard to reconcile with the fact
that pedestrian signals are frequently referred to as "traffic lights" in
many official government documents and guides and trying to understand what
in the world "their own traffic lights" means.

Personally, I think this suggests a need for a separate value or at least
tagging strategy to separate at least these two cases: signals directed at
pedestrians vs. signals directed at street traffic. If there is value in
knowing whether traffic signals are attached to the crossing in some way, I
wouldn't be against that, either.

On Fri, May 10, 2019 at 4:45 AM Paul Allen  wrote:

> On Thu, 9 May 2019 at 23:26, Nick Bolten  wrote:
>
>>
>> Yes, but a traffic light for whom? I've seen mappers who assume it means
>> "walk"/"do not walk" lights like this:
>> https://commons.wikimedia.org/wiki/File:Do_Not_Walk_sign,_Great_Neck,_New_York.jpg.
>> I've seen mappers who assume it means there is a sign *just* to warn
>> traffic about pedestrians, as can be found in the UK. I've seen mappers who
>> assume it means there is a nearby traffic light that means cars sometimes
>> stop at this location, but it doesn't say anything about having a
>> "walk"/"do not walk" sign.
>>
>
> Yes, there are warning lights in the UK.  Zebra crossings on public roads
> have a flashing yellow
> globe on a pole (Belisha Beacon) to highlight that there is a crossing.
> But nobody refers to it as
> a traffic light.  Some crossings by schools have flashing yellow lights
> (in a similar sort of style
> to US railroad crossing lights) but they're not traffic lights either.
> Traffic lights control the flow
> of traffic by telling drives when they must stop and when they can go,
> they're not warnings that
> there is a crossing.
>
> We have crossings with lights that control both pedestrians and traffic,
> the Pelican (PEdestrian
> Light CONtrolled) crossing.  As far as motorists are concerned it looks
> like any other set of
> traffic lights except there's an additional flashing amber phase telling
> cars they can go if there
> are no pedestrians on the crossing.  As far as pedestrians are concerned
> it looks like traffic
> lights for motor vehicles but also has lights for the pedestrians (and a
> button, which may or
> may not do anything) for the pedestrian to let the lights know somebody is
> waiting to cross).
>
> I don't recall seeing (in the UK, in other countries it might be
> different) lights that control
> pedestrians but NOT traffic.  It doesn't seem to be a sensible idea.  A
> signal that tells pedestrians
> it's now OK to cross without telling motorists they should have stopped
> seems like a recipe
> for disaster.
>
> To summarize: in the UK there are traffic lights that control motor
> vehicles and there are traffic lights
> that control both motor vehicles and pedestrians; warning lights are not
> traffic lights.
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Paul Allen]

On Thu, 9 May 2019 at 23:26, Nick Bolten  wrote:

>
> Yes, but a traffic light for whom? I've seen mappers who assume it means
> "walk"/"do not walk" lights like this:
> https://commons.wikimedia.org/wiki/File:Do_Not_Walk_sign,_Great_Neck,_New_York.jpg.
> I've seen mappers who assume it means there is a sign *just* to warn
> traffic about pedestrians, as can be found in the UK. I've seen mappers who
> assume it means there is a nearby traffic light that means cars sometimes
> stop at this location, but it doesn't say anything about having a
> "walk"/"do not walk" sign.
>

Yes, there are warning lights in the UK.  Zebra crossings on public roads
have a flashing yellow
globe on a pole (Belisha Beacon) to highlight that there is a crossing.
But nobody refers to it as
a traffic light.  Some crossings by schools have flashing yellow lights (in
a similar sort of style
to US railroad crossing lights) but they're not traffic lights either.
Traffic lights control the flow
of traffic by telling drives when they must stop and when they can go,
they're not warnings that
there is a crossing.

We have crossings with lights that control both pedestrians and traffic,
the Pelican (PEdestrian
Light CONtrolled) crossing.  As far as motorists are concerned it looks
like any other set of
traffic lights except there's an additional flashing amber phase telling
cars they can go if there
are no pedestrians on the crossing.  As far as pedestrians are concerned it
looks like traffic
lights for motor vehicles but also has lights for the pedestrians (and a
button, which may or
may not do anything) for the pedestrian to let the lights know somebody is
waiting to cross).

I don't recall seeing (in the UK, in other countries it might be different)
lights that control
pedestrians but NOT traffic.  It doesn't seem to be a sensible idea.  A
signal that tells pedestrians
it's now OK to cross without telling motorists they should have stopped
seems like a recipe
for disaster.

To summarize: in the UK there are traffic lights that control motor
vehicles and there are traffic lights
that control both motor vehicles and pedestrians; warning lights are not
traffic lights.
-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Paul Allen]

On Thu, 9 May 2019 at 23:46, Nick Bolten  wrote:

>
> I don't know what it means for a crossing to be supervised,
>

I assume what is meant by "supervised" is
https://en.wikipedia.org/wiki/Crossing_guard

The supervised crossing may have markings or even lights, or possibly
neither.  The lollipop
person is there for specific events (usually school start/finish) to
provide extra safety. for the
little monsters.  Could also apply to a police officer on traffic duty in
countries where traffic
lights are more expensive than police officers.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

> If there is not any control of the crossing...yes otherwise should be
crossing=traffic_signals or supervised=yes as you can read in the wiki.

But the meaning of "control" varies by region and municipality, and does
not imply the presence or absence of ground markings. A controlled crossing
can have or lack ground markings, and an uncontrolled can have or lack
ground markings.

> Well, in my country it is, when there is a traffic signals with
pedestrian traffic signal there is a crossing=traffic_signals. Otherwise is
crossing=no because there is no crossing at all.

In your country, how do you map a crossing that has traffic controls but
does not have markings on the ground?

> Change the questions:
> -Is there any traffic signal in the crossing?
> -Is there any supervision in the crossing?
> -Is there any mark in the crossing?

I don't know what it means for a crossing to be supervised, but I do like
the others you've listed. I would prefer that the crossing=* tagging schema
reflect the questions you are asking, they're the right ones for
pedestrians. What I'm saying is that the current OSM schema seems to ask
the questions I listed, but they get described by a single value like
"uncontrolled", to the confusion of all. In other words:
crossing=uncontrolled implies at least 3 pieces of information. Imagine if
we instead had a schema for your questions that looked something like this:

crossing:traffic_signal=yes/no/*
crossing:supervision=yes/no/*
crossing:marking=yes/no/* (or crossing=marked/unmarked/*)

That would be separating those questions out much better than the current
schema and be much easier to map.

> No , for a pedestrian way which passes inside an island I have
footway=crossing because there si a footway inside a island. I don't need a
tag which says things I can see in the situation for the map. It is the
same reason I don't need crossing=marked if I have crossing=uncontrolled.
Mark is not a control.

While it is not as thoroughly-documented as it could be, the wiki states
that crossing:island can be applied to the footway:
https://wiki.openstreetmap.org/wiki/Key:crossing:island. Specifically, "or
alternatively on a pedestrian crossing way highway=footway +
footway=crossing".

As an example, imagine that you are a data consumer and you want to tell a
pedestrian router that they are using an island. If you were to look up a
crossing:island key on a given footway, you could tell them, "use a traffic
island to get to ". You can, of course, also use an advanced
router that extracts crossing:island from a node.

> Well, we have it and it is called crossing_ref.

crossing_ref is not actually a tag for noting the type of markings, nor was
it intended to be. It's a dumping ground for the older UK-centric tagging
schema that used zebra, toucan, pelican, etc, with those UK-specific
right-of-way implications. For example, crossing_ref does not have a
"ladder" key, even though that's an extremely common marking type:
https://taginfo.openstreetmap.org/keys/crossing_ref#values. As you can see,
pretty much all of them are just "zebra". Many people from the UK get
annoyed when you call a US-based ladder crossing a "zebra crossing", as our
ladder crossings do not have the same right-of-way implications nor the
angled markings.

> I was talking about crossing=zebra issue.

Ah, I see. I just misunderstood, my fault.

> Tell me one situation you cannot map in detail with present tagging
scheme.

* Map a crossing that is unmarked and has pedestrian signals ("walk"/"do
not walk").
* Map a crossing that is marked and is protected by a stop sign but no
traffic light, then say how you would interpret this as a data consumer.
* Map a crossing that is unmarked and is protected by a stop sign but no
traffic light, then say how you would interpret this as a data consumer.
* Map a crossing that is unmarked and is protected by its own,
non-street-intersection traffic light, then say how you would interpret
this as a data consumer.
* Map a crossing that is unmarked, has pedestrian-specific signals
("walk"/"do not walk"), but no traffic signals at all nearby.
* Map a crossing that has markings and is protected by a traffic light, but
that traffic light is part of the overall highway=traffic_signals
signalization, not specific to just that crossing.
* Map an unmarked crossing that has the same type of traffic light
situation: the light is to stop traffic at the intersection, not that
particular crossing alone. Map an unmarked crossing that has
pedestrian-specific signals ("walk"/"do not walk") and has that same
"intersection-only" traffic light.
* Map a marked crossing where pedestrians lack the right of way.
* Map an marked crossing that has dropped curbs (keep in mind that some
veteran OSM mappers have stated that dropped curbs are a control).

I have no doubt that you can come up with some examples that *mostly* work.
But they will be ambiguous to a data consumer and often most mappers.

Best,

Nick

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

> I have checked out your proposal...and I don't know what is the
difference with a crossing=marked (yours) and a crossing=uncontrolled (in
OSM)

crossing=marked indicates that a crossing has markings. That's it: the
"type" of crossing is declared to be whether it has markings on the ground
or not.

crossing=uncontrolled has very unclear meanings. You can see from this and
the thread about crossing:signals=* that there are at least 4 different
definitions used by veteran-ish OSM mappers, despite most of them saying
"of course it means my version". To expound, there are multiple ways in
which "uncontrolled" has problems in terms of understanding meaning:

(1) The term "uncontrolled" is a transit nerd term. Almost nobody uses this
word outside of a select few circles. New mappers have no idea what it
means (though veteran mappers also seem to disagree with one another) and
make an *incorrect* guess, assuming it means the same as unmarked.

(2)  the crossing tag, as currently documented, has values that imply
meanings regarding right-of-way, markings on the ground, and
pedestrian/traffic signals (it's hard to tell what the latter even means,
honestly, which is why I have that proposal). That's three totally
different categories that are meant to be summed up in one tag value and
the current values don't even cover the full combination. "uncontrolled"
does not actually say anything about right-of-way, per the OpenStreetMap
wiki.

(3) However, the real-world meaning of "uncontrolled" is entirely about
right-of-way based on "controls" for street traffic. Essentially, it's the
polar opposite of the OpenStreetMap usage. Anyone who attempts to look up
the term "uncontrolled" outside of the OpenStreetMap will come away with
the exact wrong meaning and map the data incorrectly.

> I don't agree with you. I think you are forgotten all the other items to
tag and the others tagging schemes in OSM. Kerbs are not for cars,
cycleways are not for cars. And there are other traffic lights rather than
car traffic lights.

I don't think I understand what you mean by this. Could you please rephrase?

> It is not true. There is a wiki and also a iD which can help to
undesrtand the tagging scheme and making easier to tag that crossing.

The iD editor never uses crossing=uncontrolled. It actually uses
crossing=marked now. It is at odds with the wiki, and what the wiki says is
very different from what many people on this mailing list say
crossing=uncontrolled means.

> What is the proposal: translate crossing=uncontrolled to crossing=marked?

Only after robust discussion with local communities and with their
approval. I am not recommending any automated edits whatsoever as part of
this proposal, only suggesting that it might be possible in limited
regions, with community assent (and following all of the other protocols
regarding machine edits). I anticipate that many US-based communities would
be open to converting crossing=uncontrolled and crossing=zebra to
crossing=marked, at a minimum, given how frequently they've been edited
with iD.



I split this message in two because it was too long - I'm sending another
reply shortly.

On Thu, May 9, 2019 at 2:26 PM yo paseopor  wrote:

> I have checked out your proposal...and I don't know what is the difference
> with a crossing=marked (yours) and a crossing=uncontrolled (in OSM)
> I don't agree with you. I think you are forgotten all the other items to
> tag and the others tagging schemes in OSM. Kerbs are not for cars,
> cycleways are not for cars. And there are other traffic lights rather than
> car traffic lights.
>
> > It is also virtually impossible for any new user to know what tags to
> use and what they mean
> It is not true. There is a wiki and also a iD which can help to undesrtand
> the tagging scheme and making easier to tag that crossing.
>
> > This proposal only concerns crossing=uncontrolled (as well as the
> still-in-use crossing=zebra)
> What is the proposal: translate crossing=uncontrolled to crossing=marked?
>
> > Are you saying that all crossings with markings should be tagged,
> "uncontrolled"?
> If there is not any control of the crossing...yes otherwise should be
> crossing=traffic_signals or supervised=yes as you can read in the wiki.
>
> > Note that crossing=traffic_light does not imply whether there are
> markings on the ground
> Well, in my country it is, when there is a traffic signals with pedestrian
> traffic signal there is a crossing=traffic_signals. Otherwise is
> crossing=no because there is no crossing at all.
>
> >does the crossing have markings? Does the crossing have a pedestrian
> signal? Does the crossing have a "controlled" status (or, perhaps better,
> this can be inferred from other properties like crossing_ref, because
> nobody has any idea what "controlled" means, apparently)?
>
> Change the questions:
> -Is there any traffic signal in the crossing?
> -Is there any supervision in the crossing?
> -Is there any mark in the crossing?
>
> A 

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

> they are also intended to mean: not controlled by a traffic light (while
„marked“ likely would include traffic light crossings)

Yes, but a traffic light for whom? I've seen mappers who assume it means
"walk"/"do not walk" lights like this:
https://commons.wikimedia.org/wiki/File:Do_Not_Walk_sign,_Great_Neck,_New_York.jpg.
I've seen mappers who assume it means there is a sign *just* to warn
traffic about pedestrians, as can be found in the UK. I've seen mappers who
assume it means there is a nearby traffic light that means cars sometimes
stop at this location, but it doesn't say anything about having a
"walk"/"do not walk" sign.

The wiki only says, "Position this tag where the crossing-traffic
(pedestrian, bicycles) have their own traffic lights.". Pedestrians having
"their own" traffic lights would seem to imply the lights are specific to
the crossing and not that cross-traffic has to stop sometimes, but it does
not say which type of traffic light: cross-traffic (cars) or pedestrian
traffic. I've tended to assume it's the former, but have run into many,
many mappers who think it's the latter.

I tend to avoid mapping it at all because I don't want to add ambiguous
data to the map.

On Thu, May 9, 2019 at 2:52 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 7. May 2019, at 22:57, Nick Bolten  wrote:
> >
> > One of the primary confusions is the "uncontrolled" (and "zebra")
> values, which are, in effect, intended to mean that a crossing is "marked"
>
>
> they are also intended to mean: not controlled by a traffic light (while
> „marked“ likely would include traffic light crossings)
>
>
> Cheers, Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Martin Koppenhoefer]

sent from a phone

> On 7. May 2019, at 22:57, Nick Bolten  wrote:
> 
> One of the primary confusions is the "uncontrolled" (and "zebra") values, 
> which are, in effect, intended to mean that a crossing is "marked"


they are also intended to mean: not controlled by a traffic light (while 
„marked“ likely would include traffic light crossings)


Cheers, Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[yo paseopor]

I have checked out your proposal...and I don't know what is the difference
with a crossing=marked (yours) and a crossing=uncontrolled (in OSM)
I don't agree with you. I think you are forgotten all the other items to
tag and the others tagging schemes in OSM. Kerbs are not for cars,
cycleways are not for cars. And there are other traffic lights rather than
car traffic lights.

> It is also virtually impossible for any new user to know what tags to use
and what they mean
It is not true. There is a wiki and also a iD which can help to undesrtand
the tagging scheme and making easier to tag that crossing.

> This proposal only concerns crossing=uncontrolled (as well as the
still-in-use crossing=zebra)
What is the proposal: translate crossing=uncontrolled to crossing=marked?

> Are you saying that all crossings with markings should be tagged,
"uncontrolled"?
If there is not any control of the crossing...yes otherwise should be
crossing=traffic_signals or supervised=yes as you can read in the wiki.

> Note that crossing=traffic_light does not imply whether there are
markings on the ground
Well, in my country it is, when there is a traffic signals with pedestrian
traffic signal there is a crossing=traffic_signals. Otherwise is
crossing=no because there is no crossing at all.

>does the crossing have markings? Does the crossing have a pedestrian
signal? Does the crossing have a "controlled" status (or, perhaps better,
this can be inferred from other properties like crossing_ref, because
nobody has any idea what "controlled" means, apparently)?

Change the questions:
-Is there any traffic signal in the crossing?
-Is there any supervision in the crossing?
-Is there any mark in the crossing?

A crossing=marked would not inform if it is supervised, and also if is
there a pedestrian traffic signal controlled crossing.

> However, traffic_calming=island describes the island itself. For a
pedestrian way, use crossing:island=yes
No , for a pedestrian way which passes inside an island I have
footway=crossing because there si a footway inside a island. I don't need a
tag which says things I can see in the situation for the map. It is the
same reason I don't need crossing=marked if I have crossing=uncontrolled.
Mark is not a control.

> I mean, they are in current use, but putting that aside, that is the
point of this proposal: we should be using a specific tag for markings.
Well, we have it and it is called crossing_ref.

> I'm attempting to build community consensus by writing a proposal and
then explaining it on this mailing list.
I was talking about crossing=zebra issue.

> Yes, and I've tried many, many times.
Tell me one situation you cannot map in detail with present tagging scheme.

This is my point of view.
Health and maps (Salut i mapes)
yopaseopor

On Thu, May 9, 2019 at 5:50 PM Nick Bolten  wrote:

> > I don't know why we need a new tag scheme.
>
> Please check out my proposal, as I've laid out several reasons. As someone
> who has personally mapped thousands of crossings, the current schema is
> absolute garbage for reliably collecting accurate data that can be reliably
> interpreted by data consumers that aren't solely focused on car routing. It
> is also virtually impossible for any new user to know what tags to use and
> what they mean. You can see in this thread as well as the one in my other
> proposal regarding signals that even veteran, expert OSM users have
> different ideas on what "crossing=uncontrolled" means.
>
> > crossing=no (prohibited)
> > crossing=yes (most generic)
> > crossing=traffic_light is with traffic lights. So implies
> crossing=controlled.
> > crossing=controlled is with traffic signs or with police people or
> similar (it does not matter the marks because of the laws. Traffic signs
> are more important than road marks, and, in conflict you have to obey the
> traffic sign not the road mark.)
>
> This proposal only concerns crossing=uncontrolled (as well as the
> still-in-use crossing=zebra).
>
> > crossing=uncontrolled but with marks. So one of them implies
> crossing=uncontrolled
>
> I don't understand what you mean by "so one of them implies
> crossing=uncontrolled"? Are you saying that all crossings with markings
> should be tagged, "uncontrolled"? What if they have pedestrian signal
> lights? That's a crossing that has both, implying a contradiction.
>
> Note that crossing=traffic_light does not imply whether there are markings
> on the ground. That's the whole problem: these tags cover information
> regarding at least 3 discrete categories of information, but do not
> themselves contain the full gamut of combinations nor even all 3 in every
> value: (1) markings on the ground, (2) the "controlled" status, and (3) the
> existence of a pedestrian signal. These should be separate questions a
> mapper can easily answer: does the crossing have markings? Does the
> crossing have a pedestrian signal? Does the crossing have a "controlled"
> status (or, perhaps better, this can be inferred 

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

This subthread is doing a good job of showing why "uncontrolled" is opaque
to users and mappers, as it is primarily an issue of local legal questions
and not physical, on-the-ground features, despite the fact that
"uncontrolled" in OSM is meant to also describe those (like markings).
Because it's a matter of local legal matters, whether a crossing is
"controlled" varies from city to city, county to county, region to region,
country to country - yet mappers are asked to describe any crossing that
has markings but no "traffic signals" are "uncontrolled".

I would be surprised if the vast majority of people could certainly
describe whether a particular crossing, even one one a block away from
their residence, is "controlled". First, I'd expect wildy varying
definitions of what the word means, with most people saying, "I have no
idea". Second, if you asked them a question like, "who has the right of way
at a marked crossing? How about unmarked?", I expect similar disagreement
and lack of certainty.

The use within OSM even disagrees with the definitions available at what I
assume are the primary sources of this nomenclature, where the crossing
itself does not necessarily have any markings whatsoever, but simply lacks
all forms of controls.

On Thu, May 9, 2019 at 1:46 AM Steve Doerr  wrote:

> On 08/05/2019 22:48, Graeme Fitzpatrick wrote:
> > I thought that controlled means that their is signage / indication of
> > some form that says a driver has to stop to allow pedestrians to cross
>
> I would take it to be more than that: something that controls *when* the
> vehicles have priority and when the pedestrians do. A zebra crossing in
> the UK is uncontrolled, and a signal-controlled crossing is, er,
> controlled by signals. Maybe a lollipop lady would also be a controlled
> crossing (but only at certain times of day).
>
> --
> Steve
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

> I don't know why we need a new tag scheme.

Please check out my proposal, as I've laid out several reasons. As someone
who has personally mapped thousands of crossings, the current schema is
absolute garbage for reliably collecting accurate data that can be reliably
interpreted by data consumers that aren't solely focused on car routing. It
is also virtually impossible for any new user to know what tags to use and
what they mean. You can see in this thread as well as the one in my other
proposal regarding signals that even veteran, expert OSM users have
different ideas on what "crossing=uncontrolled" means.

> crossing=no (prohibited)
> crossing=yes (most generic)
> crossing=traffic_light is with traffic lights. So implies
crossing=controlled.
> crossing=controlled is with traffic signs or with police people or
similar (it does not matter the marks because of the laws. Traffic signs
are more important than road marks, and, in conflict you have to obey the
traffic sign not the road mark.)

This proposal only concerns crossing=uncontrolled (as well as the
still-in-use crossing=zebra).

> crossing=uncontrolled but with marks. So one of them implies
crossing=uncontrolled

I don't understand what you mean by "so one of them implies
crossing=uncontrolled"? Are you saying that all crossings with markings
should be tagged, "uncontrolled"? What if they have pedestrian signal
lights? That's a crossing that has both, implying a contradiction.

Note that crossing=traffic_light does not imply whether there are markings
on the ground. That's the whole problem: these tags cover information
regarding at least 3 discrete categories of information, but do not
themselves contain the full gamut of combinations nor even all 3 in every
value: (1) markings on the ground, (2) the "controlled" status, and (3) the
existence of a pedestrian signal. These should be separate questions a
mapper can easily answer: does the crossing have markings? Does the
crossing have a pedestrian signal? Does the crossing have a "controlled"
status (or, perhaps better, this can be inferred from other properties like
crossing_ref, because nobody has any idea what "controlled" means,
apparently)?

> If there is a traffic island in the crossing you can tag
traffic_calming=island (you can read in the wiki crossing=island is a  broken
tagging scheme .

Yes, and I'm thankful that SelfishSeahorse led the effort to fix that tag.
The two proposals I've announced are related to breaking out these
non-orthogonal crossings tags, similar to crossing=island. However,
traffic_calming=island describes the island itself. For a pedestrian way,
use crossing:island=yes.

> And then there are the crossing_ref

This is outside the scope of this proposal, aside from the fact that if
crossing=marked is used, it creates an opportunity to use a straightforward
subtag for different marking types that are currently tagged as
crossing_ref. Try explaining to virtually anyone why the crossing type is
called, "crossing_ref". What's a ref? What does it mean to apply a ref to a
crossing? With that said, this proposal does not hinge on this, it's just
an opportunity for a different proposal down the line.

> But there is no crossing=zebra or crossing=marked.

I mean, they are in current use, but putting that aside, that is the point
of this proposal: we should be using a specific tag for markings.

> I know some editor software and renders are very important for OSM, but
doing whatever you want avoiding community consensus can generate these
problems.

I'm attempting to build community consensus by writing a proposal and then
explaining it on this mailing list.

> Are you sure we need a new tagging scheme for crossings?

I am absolutely positive.

> Are you sure there is not other existing way to map whatever you want
with the present tagging scheme?

Yes, and I've tried many, many times.

Best,

Nick

On Wed, May 8, 2019 at 10:38 AM yo paseopor  wrote:

> I don't know why we need a new tag scheme.
>
> I remember my explanation of the question and the adaptation of the
> possibilities. I repeat them here:
>
> crossing=no (prohibited)
> crossing=yes (most generic)
>
> crossing=traffic_light is with traffic lights. So implies
> crossing=controlled.
> crossing=controlled is with traffic signs or with police people or similar
> (it does not matter the marks because of the laws. Traffic signs are more
> important than road marks, and, in conflict you have to obey the traffic
> sign not the road mark.)
> crossing=uncontrolled but with marks. So one of them implies
> crossing=uncontrolled
> crossing=unmarked with no marks, with no control, but crossing
>
> If there is a traffic island in the crossing you can tag
> traffic_calming=island (you can read in the wiki crossing=island is a  broken
> tagging scheme .
>
> And then there are the crossing_ref
>
> zebra is marked but uncontrolled (if it is controlled you can use other
> value)
> pelican,panda,tigger,toucan,pegasus are controlled with 

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

> I suggest that you read the discussion I started in December
about crossing=zebra because it is the main cause of the current situation.

I read it back in December, but I disagree. The cause of the situation is
the huge problems with the crossing=* values for marked crossings. That
problem also caused the iD editor to use its zebra and now marked presets.

> Bryan replaced crossing=zebra with crossing=marked in iD but as the
crossing=zebra problems were not understood, the alternative has exactly
the same problems as the replaced solution.

Such as...?

> the crossing key is however simple to use except for badly chosen values
does the passage have a fire? crossing=traffic_signals otherwise, does the
passage have a marking on the ground?  crossing=uncontrolled (the work is
not perfect because a marking a kind of controll) otherwise
crossing=unmarked

I don't understand what you're saying here (fire?), but would be interested
in knowing what you mean. Could you please rephrase?

> Last year, I have review ~1k crossing=zebra, the fragmentation is mainly
due to iD

I'd expect quite a few tags to come from iD, as it's the default editor on
openstreetmap.org, of course. I'm curious about your methodology, since I
don't remember seeing this in that December thread. How did you sample?
What were the results?

> for now, the "new" iD preset destroys perfectly valid data at a
frightening rate! if someone modifies a pedestrian crossing with a light,
iD replaces it
with crossing=marked, which disrupts the information of the presence of the
light.

This is not relevant to my proposal. Please keep unrelated gripes regarding
editors to another thread.

> There is already a tag for the reference of a crossing.

I'm aware. Please read my proposal, where I explicitly discuss this.

> a bad preset is not a good usage

Please explain why it's a bad preset.

Best,

Nick

On Wed, May 8, 2019 at 1:51 AM marc marc  wrote:

> Le 07.05.19 à 22:57, Nick Bolten a écrit :
> > - crossing=* values are not truly orthogonal and this needs to be
> > addressed. e.g., "uncontrolled", "traffic_signals", and "unmarked" are
> > not truly orthogonal descriptors.
>
> I suggest that you read the discussion I started in December about
> crossing=zebra because it is the main cause of the current situation.
> Bryan replaced crossing=zebra with crossing=marked in iD but as the
> crossing=zebra problems were not understood, the alternative has exactly
> the same problems as the replaced solution.
> the crossing key is however simple to use except for badly chosen values
> does the passage have a fire? crossing=traffic_signals
> otherwise, does the passage have a marking on the ground?
> crossing=uncontrolled (the work is not perfect because a marking a kind
> of controll)
> otherwise crossing=unmarked
>
> >- There is fragmentation in tag usage for marked crossings between
> > "zebra" and "uncontrolled".
>
> Last year, I have review ~1k crossing=zebra,
> the fragmentation is mainly due to iD
>
> >- crossing=marked is direct and clear about its meaning and use cases.
>
> for now, the "new" iD preset destroys perfectly valid data
> at a frightening rate!
> if someone modifies a pedestrian crossing with a light, iD replaces it
> with crossing=marked, which disrupts the information of the presence of
> the light.
> There is already a tag for the reference of a crossing.
> if the reference is not known, it would be easy to use crossing_ref=yes
> as it is done with many keys.
>
> > - crossing=marked is already in use and supported by various editors,
> > including being the default in iD
>
> a bad preset is not a good usage
>
> Regards,
> Marc
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Steve Doerr]

On 08/05/2019 22:48, Graeme Fitzpatrick wrote:
I thought that controlled means that their is signage / indication of 
some form that says a driver has to stop to allow pedestrians to cross


I would take it to be more than that: something that controls *when* the 
vehicles have priority and when the pedestrians do. A zebra crossing in 
the UK is uncontrolled, and a signal-controlled crossing is, er, 
controlled by signals. Maybe a lollipop lady would also be a controlled 
crossing (but only at certain times of day).


--
Steve

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Clifford Snow]

On Wed, May 8, 2019 at 2:48 PM Graeme Fitzpatrick 
wrote:

>
> Now we may (yet again!) be getting caught up in the
> one-word-different-meanings-worldwide saga, but, in Australia at least,
> "zebra" crossings (parallel alternating black & white stripes crossing the
> road) are controlled - they signify a pedestrian crossing & drivers must
> stop & give way to any pedestrians on or approaching the crossing.
>
> So are there different rules elsewhere, so that you can say "zebra is
> marked but uncontrolled"?
>

Where I live in the US, Washington State, a pedestrian has the right of way
at any intersection unless otherwise indicated. Other places the pedestrian
only has the right of way in marked crossings.  But a marked crossing
doesn't necessarily mean controlled. To me that means some sort of signal.
Similar to the way we tag supervised crossings  highway=crossing +
crossing=* as appropriate + supervised=yes

Best,
Clifford
-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Graeme Fitzpatrick]

On Thu, 9 May 2019 at 03:38, yo paseopor  wrote:

> zebra is marked but uncontrolled
>

Maybe (quite possibly!) I'm getting confused over the whole controlled /
uncontrolled concept?

I thought that controlled means that their is signage / indication of some
form that says a driver has to stop to allow pedestrians to cross; while
uncontrolled basically equals unmarked - there is provision made (gutter
ramps etc) to allow people to easily cross the road, but there are no
crossing markings of any sort eg
https://www.google.com/maps/@-28.070894,153.4363207,3a,75y,302.12h,81.73t/data=!3m5!1e1!3m3!1s9ZbzIxzGlFkj8GrFmiQ38Q!2e0!6s%2F%2Fgeo0.ggpht.com%2Fcbk%3Fpanoid%3D9ZbzIxzGlFkj8GrFmiQ38Q%26output%3Dthumbnail%26cb_client%3Dmaps_sv.tactile.gps%26thumb%3D2%26w%3D203%26h%3D100%26yaw%3D336.35266%26pitch%3D0%26thumbfov%3D100
,
however a driver must still stop to allow pedestrians to cross?

Now we may (yet again!) be getting caught up in the
one-word-different-meanings-worldwide saga, but, in Australia at least,
"zebra" crossings (parallel alternating black & white stripes crossing the
road) are controlled - they signify a pedestrian crossing & drivers must
stop & give way to any pedestrians on or approaching the crossing.

So are there different rules elsewhere, so that you can say "zebra is
marked but uncontrolled"?

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[marc marc]

Le 08.05.19 à 19:37, yo paseopor a écrit :
> zebra is marked but uncontrolled (if it is controlled you can use other 
> value)

but if you see a zebra with satellite image, you often have no idea if a 
the crossing have a traffic light or not in a lot of country (like in 
Belgium/France/Luxembourg/Switzerland)

that's why I proposed that iD change its preset: if someone sees a zebra 
on a satellite image, the only thing that can be added is 
crossing_ref=zebra. crossing=zebra does not allow incremential mapping 
(= one user add info from sat, another user add info from survey)
that's why it doesn't make sense to have the type of marking in the same 
tag as the one that talks about the presence of a light.
unfortunately both the previous preset and the current one lead to the 
destruction (voluntary since the author has been warned for a long time) 
of the crossing=traffic_signals sometimes already present.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[yo paseopor]

I don't know why we need a new tag scheme.

I remember my explanation of the question and the adaptation of the
possibilities. I repeat them here:

crossing=no (prohibited)
crossing=yes (most generic)

crossing=traffic_light is with traffic lights. So implies
crossing=controlled.
crossing=controlled is with traffic signs or with police people or similar
(it does not matter the marks because of the laws. Traffic signs are more
important than road marks, and, in conflict you have to obey the traffic
sign not the road mark.)
crossing=uncontrolled but with marks. So one of them implies
crossing=uncontrolled
crossing=unmarked with no marks, with no control, but crossing

If there is a traffic island in the crossing you can tag
traffic_calming=island (you can read in the wiki crossing=island is a  broken
tagging scheme .

And then there are the crossing_ref

zebra is marked but uncontrolled (if it is controlled you can use other
value)
pelican,panda,tigger,toucan,pegasus are controlled with traffic lights
pelican and panda is only with traffic lights .Pelican is the evolution of
panda
tigger means bicycle=designated and toucan means bicycle=yes.
pegasus means horse=designated
 (all of these are from U.K.)

But there is no crossing=zebra or crossing=marked.
I know some editor software and renders are very important for OSM, but
doing whatever you want avoiding community consensus can generate these
problems.
Are you sure we need a new tagging scheme for crossings? Are you sure there
is not other existing way to map whatever you want with the present tagging
scheme?

I don't think so
Health and maps (Salut i mapes)
yopaseopor


On Wed, May 8, 2019 at 10:51 AM marc marc  wrote:

> Le 07.05.19 à 22:57, Nick Bolten a écrit :
> > - crossing=* values are not truly orthogonal and this needs to be
> > addressed. e.g., "uncontrolled", "traffic_signals", and "unmarked" are
> > not truly orthogonal descriptors.
>
> I suggest that you read the discussion I started in December about
> crossing=zebra because it is the main cause of the current situation.
> Bryan replaced crossing=zebra with crossing=marked in iD but as the
> crossing=zebra problems were not understood, the alternative has exactly
> the same problems as the replaced solution.
> the crossing key is however simple to use except for badly chosen values
> does the passage have a fire? crossing=traffic_signals
> otherwise, does the passage have a marking on the ground?
> crossing=uncontrolled (the work is not perfect because a marking a kind
> of controll)
> otherwise crossing=unmarked
>
> >- There is fragmentation in tag usage for marked crossings between
> > "zebra" and "uncontrolled".
>
> Last year, I have review ~1k crossing=zebra,
> the fragmentation is mainly due to iD
>
> >- crossing=marked is direct and clear about its meaning and use cases.
>
> for now, the "new" iD preset destroys perfectly valid data
> at a frightening rate!
> if someone modifies a pedestrian crossing with a light, iD replaces it
> with crossing=marked, which disrupts the information of the presence of
> the light.
> There is already a tag for the reference of a crossing.
> if the reference is not known, it would be easy to use crossing_ref=yes
> as it is done with many keys.
>
> > - crossing=marked is already in use and supported by various editors,
> > including being the default in iD
>
> a bad preset is not a good usage
>
> Regards,
> Marc
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[marc marc]

Le 07.05.19 à 22:57, Nick Bolten a écrit :
> - crossing=* values are not truly orthogonal and this needs to be 
> addressed. e.g., "uncontrolled", "traffic_signals", and "unmarked" are 
> not truly orthogonal descriptors.

I suggest that you read the discussion I started in December about 
crossing=zebra because it is the main cause of the current situation.
Bryan replaced crossing=zebra with crossing=marked in iD but as the 
crossing=zebra problems were not understood, the alternative has exactly 
the same problems as the replaced solution.
the crossing key is however simple to use except for badly chosen values
does the passage have a fire? crossing=traffic_signals
otherwise, does the passage have a marking on the ground? 
crossing=uncontrolled (the work is not perfect because a marking a kind 
of controll)
otherwise crossing=unmarked

>    - There is fragmentation in tag usage for marked crossings between 
> "zebra" and "uncontrolled".

Last year, I have review ~1k crossing=zebra,
the fragmentation is mainly due to iD

>    - crossing=marked is direct and clear about its meaning and use cases.

for now, the "new" iD preset destroys perfectly valid data
at a frightening rate!
if someone modifies a pedestrian crossing with a light, iD replaces it 
with crossing=marked, which disrupts the information of the presence of 
the light.
There is already a tag for the reference of a crossing.
if the reference is not known, it would be easy to use crossing_ref=yes 
as it is done with many keys.

> - crossing=marked is already in use and supported by various editors, 
> including being the default in iD

a bad preset is not a good usage

Regards,
Marc
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging