Ontario pedestrian crossover (PXO) tagging

Jarek · August 27, 2024, 2:28am

Does anyone have thoughts on recommendations on tagging the different types of PXOs?

Official or semi-official resources identify 3 or 4 types or crossings that seem higher-level than plain crosswalks.

Ref:

I have previously used GitHub - BikeOttawa/OSM-Bike-Ottawa-Tagging-Guide: OSM Bike Ottawa Tagging Guide which suggests
crossing=controlled + flashing_lights=always/button (in my experience for PXOs it’s usually button), but I’m not sure if the tag crossing=controlled is going to survive users of validators of various editors, be it iD or StreetComplete or whatever.

I would suggest creating an updated tagging guideline that takes the different PXO types into account and suggests tags for them.

Would it be useful to tag the type of the PXO itself, for example crossing_ref:CA:ON=PXO Type B or similar? (e.g.)

Or perhaps we should try to identify functional features of the different types? For example Type A PXOs have overhead lights that shine down onto the crossing, so something like crossing:illuminated=yes? There’s about a hundred uses of crossing:light=yes for this in Toronto (e.g.) - I see now this is intended for railway crossings, but might be in an iD preset for pedestrian crossings too?

Is button_operated=yes needed when flashing_lights=button is tagged?

What have others used?

What would others suggest as tagging?

Jarek · September 10, 2024, 1:54am

I have checked what StreetComplete, Every Door, and iD do with a crossing tagged crossing=uncontrolled and crossing=controlled and:

StreetComplete asks for crossing:island and tactile_paving if those are not tagged
Every Door has fields to select values for tactile_paving, crossing:island, crossing:markings, and flashing_lights (supporting button, yes, always)
iD has fields to select values for tactile paving, refuge island, markings, “raised” (adding traffic_calming=table) and flashing lights. crossing:light=yes does not appear to be selectable by default in iD
none of them suggests to change controlled to anything else

So:

feasibly we could keep crossing=controlled and it won’t be resolving-issues’d at least for now
of PXO characteristics, flashing_lights=button appears to be the most widely supported

Minh_Nguyen · September 10, 2024, 2:22am

Unless there’s a risk that Québec or Michigan has deemed a crossing in Ontario to be something other than a PXO Type B, the CA:ON: qualifier can probably go in a normal crossing_ref=* tag rather than a separate crossing_ref:CA:ON=* subkey. However, this would fragment the existing collection of crossing_ref=pxo, making it slightly more difficult to query for PXOs in general. Another option would be something like designation=pxo_type_b, since for better or worse, designation=* values are already implicitly regional.

Jarek · September 10, 2024, 2:41am

Ah yeah, that makes sense, better idea - thanks! crossing_ref=CA:ON:PXO:Type B?

Oh interesting, I haven’t actually seen that tag before - looks to be used in Ottawa. Maybe we could even use something like crossing_ref=pxo:Type B since per Taginfo it doesn’t look like “PXO” is used for anything else anyway.

To me it’s still an open question if it’s worth tagging the “type” as opposed to only its features (crossing:markings, crossing:lit, flashing_lights), and if yes, what to do about any potential crossings that don’t exactly match the “type” examples.

Minh_Nguyen · September 10, 2024, 3:36am

I’m not particularly familiar with the type classifications for PXOs or what folks may consider important about them.

In general, renderers and routers can readily interpret tags like crossing:markings=* and flashing_lights=* literally. Data consumers can use crossing_ref=* too, for hyperrealistic rendering. However, most common values don’t specify a region, so the data consumer would have to infer that somehow – that could hamper uptake a bit. Unless editors try to infer a formal type designation from a combination of crossing tags, other mappers may appreciate crossing_ref=* as a high-level “summary” of the other tags.

Jarek · October 23, 2024, 6:18pm

For the record, this page seems to have been moved to https://www.markham.ca/neighbourhood-services/walking-and-cycling/walking/pedestrian-crossoverspxos, unfortunately without a redirect, and I can’t seem to edit my post anymore.

I have been tagging some more PXOs and will write up a tagging proposal based on the experiences soon.

Jarek · November 6, 2024, 6:20pm

A test PXO Type C I mapped:

crossing:island=no
crossing:lit=no
crossing:markings=ladder
crossing=uncontrolled
crossing_ref=pxo:Type C
flashing_lights=button
highway=crossing
tactile_paving=yes

This should also work for Type B, with changing only the crossing_ref. Difference between Type B and Type C seems to be whether there are also crossing signs hanging over the roadway - I’m not sure this is significant enough to warrant tagging other than in crossing_ref.

tactile_paving and crossing:markings would depend on what is actually the case at the PXO (e.g. many older Toronto PXOs don’t have tactile paving).

I believe crossing:island=no is going to be the case for all Ontario PXOs (or nearly all), but I tagged it as otherwise I’m sure iD or StreetComplete will ask and someone will add it later separately.

I tagged crossing:lit=no on the node to mean that the crossing itself is not specifically lit unlike Type A PXOs. I used the crossing: prefix to indicate that it’s the crossing that’s not lit: the street itself as a whole is lit, but there’s no light that focuses just on the crossing that makes pedestrians in it more visible. @mueschel then changed this tag to lit=no without commenting. @mueschel can you comment on this thread please? Do you believe that lit should always be used in this case?

button_operated=yes is another tag that’s been used on some PXOs but I think flashing_lights=button covers their functionality better. Also, according to wiki, crossing:light refers to railway crossings, and I think crossing:lit and flashing_lights describe it less ambiguously (what kind of light).

I think I’m pretty happy with this tagging, it captures what to me seem to be the essential features of a PXO (flashing_lights, markings, Type C being unlit) and has the crossing_ref for legal classification.

Suggested tagging for Type A (lit from overhead):

crossing:lit=yes
crossing:markings=[as appropriate]
crossing=uncontrolled
crossing_ref=pxo:Type A
flashing_lights=button
highway=crossing

Suggested tagging for Type D (only sign - this is essentially a regular crosswalk, except possibly mid-block, and with signs):

crossing:lit=no
crossing:markings=[as appropriate]
crossing=uncontrolled
crossing_ref=pxo:Type D
flashing_lights=no
highway=crossing

Minh_Nguyen · November 6, 2024, 7:40pm

Would you consider this prefix necessary if the crossing is also modeled as a highway=footway footway=crossing way?

Jarek · November 7, 2024, 12:25am

Well, lit=no on a PXO Type B or C way seems a bit confusing: if the road being crossed is lit, then the crossing is generally lit by streetlights, so in human terms it’s not not lit, but it’s not lit specifically as the crossing.

Moreover, this brings us into whether crossing tags go on node, way, or both which seems quite messy, with different editors currently defaulting to different actions (StreetComplete and Every Door only allow tagging the node, iD invites tagging both). It seems that if anything, many tags are duplicated between node and way. So it’s probably a bad idea to have a tag that would have different semantics on the node vs on the way.

Perhaps we could avoid this issue by declaring that the overhead light isn’t significant enough as a feature and omitting the tag altogether? Then only crossing_ref would distinguish PXO Types A, B, and C.

Here’s what a PXO Type A in Toronto looks like in practice, to the extent that a phone camera can capture:

(Note the streetlight immediately next to the crossing, yet the crossing light is brighter)

Minh_Nguyen · November 7, 2024, 12:51am

Ah, I thought you were referring to a streetlight. I had forgotten about the illuminated Overhead X signs. Even if they’re brighter, they don’t face the crossing, and I don’t think they’re primarily designed to brighten anything. The most pedantic approach would be to tag the traffic_sign=CA-ON:Wc-20 or CA-ON:Wc-120 node with luminous=yes, but obviously that’s another level of micromapping than what you’re interested in here. I would just omit that detail, but it sure would be nice if we had an established tag to say that the crossing is signposted in the first place.

Jarek · November 7, 2024, 1:02am

Hm, I would consider the ones on the picture – which is Toronto’s usual design – to purposefully direct light down onto the crossing.

A few more pictures – note the three-dimensional shape of the overhead lamps to give a lens for the light to shine down:

Minh_Nguyen · November 7, 2024, 1:33am

Oh OK, my bad. Well, if it is on purpose and you think tagging it as lit wouldn’t surprise a layperson, then that sounds pretty clear. As far as I know, lit=yes on a highway=crossing node wouldn’t result in too much confusion among existing data consumers, which mostly expect the tag on a highway=* way or some kind of POI like a bus stop. It won’t gum up a router in the same manner as, say, access=no. It also won’t take on a subtly different meaning like tactile_paving=yes.^[1]

On a crossing node, tactile_paving=yes means the curb cuts have tactile paving, whereas on a crossing way, the same tag means tactile paving extends all the way across the street along the crossing. ↩︎