Talk:Draft:Foundation/Local Chapters/United States/Pedestrian Working Group/Schema

Please contribute any comments, suggestions, concerns, etc. on this page by creating a new topic below this line or replying to ongoing discussions.

---

Should surface and width tags really be required (or even allowed) on the node as well as the way?

Currently, surface=* is apparently required by the PWG schema on the crossing node as well as the way. However, while surface=* is widely used and understood on ways, I don't know if I've ever seen it on nodes, except for crossing:continuous=yes minor residential driveway crossings that were node-only. Per TagInfo, while 30% (643k) of crossing ways (footway=crossing) in the US have surface=*, a mere 0.10% (3.5k) crossing nodes (highway=crossing) have a surface=* value. (Worldwide, this is 37% (1730k) to 0.20% (23k).) Given it has no crossing-specific purpose beyond its normal use on the way, I'm not sure I see a sufficiently strong rationale to require (or even encourage) it on the node to offset encouraging a lot of churn, duplication and potential loss-of-sync as well as disqualifying an overwhelming majority of otherwise-valid crossings from being PWG Silver Tier compliant. CAM-Gerlach (talk) 16:18, 19 August 2025 (UTC)

A similar rationale would apply to width=* as well, given it seems some use on crossing ways (23.7 k uses worldwide, 5.2k US or 0.51% / 0.24% of crossing ways respectively) and has a clear precedent, use and consumption on highway=* ways in general and is not specific to crossings, whereas it is so little used on crossing nodes that it doesn't show up in TagInfo's statistics at all (<0.01%), either in the US (<200) or worldwide (<1000). CAM-Gerlach (talk) 16:24, 19 August 2025 (UTC)

There is definitely a lot of duplication between highway=crossing nodes and footway=crossing ways. We should discuss this during today's meeting! --UW Amy Bordenave (talk) 16:48, 19 August 2025 (UTC)

In general I don't see the need to add much metadata to the crossing node, and I'd prefer to leave those tags out of our schema (even if they are correct to use). Since we already require surface tags along the crossing way, surface=* has little value on the node and could either duplicate or conflict with the way's tags. Crossing nodes smell like road-based tagging, which is unnecessary when we map these features separately. Same with tactile_paving=*: instead of tagging the crossing node, we should be tagging the curb node(s) (or a node tagged with kerb=no). Jacobwhall (talk) 20:33, 19 August 2025 (UTC)

Wiki page for button_operated says only valid on nodes, while PWG schema requires it on ways

The button_operated=* wiki page and data item specify that it is only valid on crossing nodes, while the PWG schema at Gold and above requires it on the crossing way as well. A specific rationale for the former restriction is not mentioned, but I seem to recall reading somewhere that (like tactile_paving=*) it could be interpreting as saying the physical crossing way itself is operated by the button, as opposed to the button being at the crossing point, in addition to it being more work to sync. Hoewver, it doesn't seem that strongly compelling and the the restriction feels a bit inconsistent with e.g. the traffic_signals=* subkeys and others that are allowed on ways, so I'm not necessarily convinced it isn't the button_operated=* wiki page/data item that needs to change. Looking at actual usage, there is a nearly 10:1 ratio of Node:Way usage worldwide, there is a 10x ratio, but only a 3:1 ratio in the US where crossings as ways is much more common, which once adjusted for the relative prevalence of crossing nodes vs. ways is better than 2:1. CAM-Gerlach (talk) 16:40, 19 August 2025 (UTC)

In a perfect world, I think we'd actually use a crossing:signals:*=* namespace: crossing:signals:button=*, crossing:signals:arrow=*, crossing:signals:vibration=*, crossing:signals:minimap=*, crossing:signals:sound=* etc. but I don't think that's likely to happen, so I haven't pushed for it. To do so would require a formal proposal, an automated edit to update the existing tags, pull requests for apps like StreetComplete, and more - all pretty much out of scope for the PWG. --UW Amy Bordenave (talk) 16:58, 19 August 2025 (UTC)

personally I don't see why button_operated=* would not be allowed on crossing ways but I would be opposed to using crossing:signals:button=* or anything based on crossing:signals:*=* as I have issues with the crossing:signals=* tag Udarian (talk) 23:09, 19 August 2025 (UTC)

[Resolved] Move `traffic_signals:minimap` to Diamond Tier

Resolved: Approved by PWG consensus and implemented. Thank you, Jacobwhall, CAM-Gerlach, and Udarian! --UW Amy Bordenave (talk) 22:18, 19 August 2025 (UTC)

As of 2025-08-03, according to Taginfo (source) there are only 1,052 uses of traffic_signals:minimap=* in the US and 1,039 (98.76%) are no. Given that this is such a rare tag, and that APS with tactile minimaps are very uncommon in the US, I propose that we move the key to the Diamond Tier. Lumikeiju (talk) 21:41, 3 August 2025 (UTC)

Agreed; this would follow a similar rationale as the Diamond classification of crossing:flags=* that several times more yes values than this, it seems to me. CAM-Gerlach (talk) 16:05, 19 August 2025 (UTC)

I agree. It would be nice for traffic_signals:minimap=* and tags like it to be moved down into the gold tier after they see more development and use in OSM as a whole. For now, it is a specialty tagging system with little adoption so it is a stretch even for the gold tier. Your point about how rare tactile minimaps are in the U.S. is a good one. Jacobwhall (talk) 20:37, 19 August 2025 (UTC)

I also think that moving `traffic_signals:minimap` to Diamond makes sense as this tag essentially requires you to survey it it Udarian (talk) 21:35, 19 August 2025 (UTC)

[Resolved] Multi-Tier Schema Table

Resolved: Approved by PWG consensus and implemented. Thank you, Thompsondt! --Lumikeiju (talk) 01:08, 4 August 2025 (UTC)

Tag	Bronze	Silver	Gold	Diamond
highway=*	footway	--	--	--
footway=*	crossing	--	--	--
crossing:markings=*	Are markings present?: yes, or no	In the silver tier, this tag becomes more specific, ex: zebra, or lines, or any other valid value	--	--
crossing:signals=*	Are signals present?: yes, or no	--	--	In the diamond tier, this tag becomes more specific, ex: shared, or dedicated
tactile_paving=*	n/a	Is tactile paving present?: yes no partial (may be used to describe a crossing node where tactile paving is present on one side of the crossing but not the other.)	--	--
surface=*	n/a	Required in the silver tier, example values include: concrete asphalt	--	--
crossing:island=*	n/a	Required in the silver tier.	--	--
button_operated=*	n/a	n/a	Required in the gold tier.	--
traffic_signals:arrow=*	n/a	n/a	Required in the gold tier.	--
traffic_signals:vibration=*	n/a	n/a	Required in the gold tier.	--
traffic_signals:minimap=*	n/a	n/a	Required in the gold tier.	--
traffic_signals:sound=*	n/a	n/a	In the gold tier, this tag becomes more specific: yes no	If acoustic signals are present for finding the button only:traffic_signals:sound=locate If acoustic signals are present for walk permission only: traffic_signals:sound=walk
width=*	n/a	n/a	Required in the gold tier.	--

Does the existing formatting not communicate this effectively? For example:

• Crossing Node and Way Tagging:

crossing:markings=* - Specify presence and type of markings

crossing:markings=no - No markings

crossing:markings=yes - Markings present, type unspecified

crossing:markings=zebra - Zebra markings

crossing:markings=lines - Lines markings

crossing:markings=* - Any other applicable value

-- UW Amy Bordenave (talk) 21:20, 18 February 2025 (UTC)

@UW Amy Bordenave: The table is a work in progress as I clumsily try to port my notes from markdown format. The color coding of the list does support scanning and it is comprehensive. The nesting also communicates the different levels of specificity. The problem I'm trying to solve with the table is visual overwhelm when scanning with a specific tier in mind. When I scan the list, I get visual interference and struggle to mentally filter for the relevant tags. By separating the information on two axes I can scan down for the tag and across for the tier. I can also scan across for the tier and then down for the tags. -- Thompsondt (talk) 21:49, 18 February 2025 (UTC)

@Thompsondt: Makes sense - thanks for the explanation. Some formatting advice - {{Value|yes}} results in yes (to use in place of the markdown "`example`" formatting. :) -- UW Amy Bordenave (talk) 21:54, 18 February 2025 (UTC)

@UW Amy Bordenave: Sounds good. I'm fine with continuing to experiment with it... On formatting, I've got to shift my head back into Wiki mode. I had thought I'd post my notes to my GitHub, but figured I'd pitch it here first. --Thompsondt (talk) 22:55, 18 February 2025 (UTC)

[Resolved] Add `crossing:signed` to Gold Tier

Resolved: Approved by PWG consensus and implemented. --UW Amy Bordenave (talk) 04:52, 30 September 2025 (UTC)

I would like to propose the addition of the crossing:signed=* tag to the PWG Schema in the Gold Tier.
Pending approval of this, I will also propose adding RRFB tagging guidance to the PWG Guide, based on the outcome of the discussions had in the following thread on the OSM Forum: Rectangular Rapid Flashing Beacons (RRFB) UW Amy Bordenave (talk) 18:25, 5 September 2025 (UTC)

I don't see why we wouldn't add it to the Gold tier and I definitely think that we should provide documentation for dealing with RRFB's, although I am not 100% happy with the existing tagging as I articulated in that forum page I do think it is better to have something vs nothing and we can improve tagging latter down the line once the community figures out some of the smaller detail surrounding RRFB's and similar objects. Udarian (talk) 22:31, 8 September 2025 (UTC)

[Resolved] Update to sidewalk-tagging guidance in Roadways section

Resolved: Approved by PWG consensus and implemented. --UW Amy Bordenave (talk) 05:32, 30 September 2025 (UTC)

Currently, the Roadways section says:

To support consistency and clarity in pedestrian infrastructure data, the US Pedestrian Working Group recommends avoiding the use of sidewalk=yes to indicate the presence of sidewalks along a street. Please consider using one of the following:

Suggested replacement:

To support consistency and clarity in pedestrian infrastructure data, the PWG recommends avoiding the use of sidewalk=* and [[Key:sidewalk|sidewalk:Template:TagVariable]]=yes to indicate the presence of sidewalks along a street. Instead, use one of the following:

Rationale:

Make explicit the recommendation against using the older sidewalk=* key as well as the yes value on the [[Key:sidewalk|sidewalk:Template:TagVariable]]=* key. From previous discussions during the monthly PWG meetings, we agreed that the yes value is not in line with PWG's goals because we start with separate geometry in the Bronze Tier.

Feedback? Suggestions? Opposition? Discuss! Lumikeiju (talk) 21:29, 3 August 2025 (UTC)

This makes sense to me, except for sidewalk=no—unlike the other values, it is not equivalent to or a refinement of the discouraged yes and is as valid and unambiguous to use when separately-mapping sidewalks as it is with the discouraged approach, and is equal to the accepted sidewalk:both=no. Currently, even in the US where separate sidewalks are roughly half or more of all sidewalks, sidewalk=no is | overwhelmingly more popular than sidewalk:both=no by well over an order of magnitude (15x, 338k vs 21.5k). Furthermore, at least per TagInfo the former has wider editor and tool support. I don't think we should encourage an immense amount of mechanical churn away from a valid, unambiguous and more established and widely-supported value that is otherwise perfectly compatible with the PWG schema, while also disqualifying a substantial number of otherwise fully PWG-compliant sidewalks from conforming based only on what in programming we'd call mere "spelling". To be clear, I certainly don't suggest that sidewalk:both=no be discouraged, just that the rationale cited for recommending against the other sidewalk tags doesn't apply to sidewalk=no. CAM-Gerlach (talk) 15:57, 19 August 2025 (UTC)

Definitely a fair point! Let's discuss this during today's meeting.
[Edit: We weren't able to get to this today - let's keep this topic on the agenda!]
[Edit 2: We discussed and approved this proposal during the 2025-09-16 PWG meeting.] --UW Amy Bordenave (talk) 16:35, 19 August 2025 (UTC)

I support this proposal. Jacobwhall (talk) 20:38, 19 August 2025 (UTC)

I also support this proposal. Udarian (talk) 21:33, 19 August 2025 (UTC)