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)

There is the One feature, one OSM element rule, but in this case, the crossing is one representation and the where it crosses with a highway line is a warning to vehicle routings, and there is no viable solution around it. As for tactile_paving=*, it is still good to map it for the crossing , as some routings might not recognize kerb=* tags. But i agree it's doubling the information --Yog Sot (talk) 23:04, 20 November 2025 (UTC)

The broader and more complex question of tags on the way versus the node aside, which would of course require a more in depth discussion, I thought we'd addressed this but it seems we got rather sidetracked here by that and never got around to the straightforward and unambiguous immediate fix of removing the spurious requirement of surface and width on the node, leaving the vast majority of otherwise Silver tier and Gold tier crossings technically non-compliant with the schema as written. Unfortunately, we already released 1.0.0 which means we'll need to bump the version again for this, although given it is loosening a mistaken existing requirement rather than adding a new one (and is thus backwards compatible) and given the precedent of fixing the similarly-erroneous footway= tag on crossing nodes in a micro release (1.0.1), we could do the same here with 1.0.2. I'd like to get this addressed as soon as practical to avoid tools like the Visualizer flagging otherwise Silver tier crossings as Bronze based on this mistaken requirement, but realistically we should wait for the next meeting and make the change then to be able to ensure we have consensus and hear any last objections. CAM-Gerlach (talk) 07:07, 4 March 2026 (UTC)

Defining the width of a crossing

A related issue: I see that tagging the width=* is required for the gold tier, but I don't see guidance on how the width of a crossing is defined, neither here, nor on the footway=crossing page. Is it the narrowest point? Do the road markings define the crossing width (and does that differ depending on the marking type, like transverse lines vs continental/zebra)? The curb ramp width at the curb? What about crossings that differ in their width from one curb to the other? --Hobbesvsboyle (talk) 13:13, 20 November 2025 (UTC)

In my city, it would be difficult to define a "width" for a road crossing. Even where there are lines painted on the ground, they are often painted in a way that does not reflect where a pedestrian would walk. I wonder, when would it be useful to tag the width of a crossing? --Jacobwhall (talk) 20:44, 17 February 2026 (UTC)

I think width is wanted so routing tools can avoid ways where a wheelchair cannot fit. For this reason, I've assumed the narrowest measurement should be preferred for width=*. If that's true, then it should be documented. If that is not true, then perhaps we should add width:min=* and width:max=*, but I'd want to know why we care about anything but the narrowest part. I'm not sure if there's much value in adding width=* to the crossing ways (let alone crossing nodes) since those are almost always wider than the curb openings at the ends. Perhaps we should recommend width=* on the curb nodes. AngryPen (talk) 00:08, 19 February 2026 (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. However, 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] footway=crossing on a node?

Resolved: Fixed. Thank you, Tomas J! --Lumikeiju (talk) 04:03, 31 January 2026 (UTC)

Hi, you suggest to use highway=crossing + footway=crossing on a node here (section Mapping guidelines -> Crossings -> Crossing Node Mapping) but at the same time you do not recommend it to use here (section Tagging guidelines -> Crossings, "NOTE: The footway=* tag is not used on crossings mapped as nodes"). Which section is the correct one? --Tomas J 30 January 2026

Good catch - that's definitely an error. I'll fix it. footway=crossing should not be added to ways! Lumikeiju (talk) 02:57, 31 January 2026 (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 sidewalk:(left|right|both)=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 sidewalk:<side>=* 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)

Clarification to crossing-tagging on nodes/ways

At the moment the schema suggest several tags should be added to the crossing node as well as the crossing way. From my point of view it makes sense to not keep the same information at two spots (and hope the best, they are equal). I would propose to be more specific on which element which information should be tagged. Like add crossing:markings=* only to the way (since this is a property of the way itself), same as surface=* or width=*. Whereas crossing:signals=* and everything related like button_operated=* and traffic_signals=*-related tags. Last, everything related to kerb=* as well as tactile_paving=* would be best tagged on the kerb-node. Aighes (talk) 18:31, 15 February 2026 (UTC)

Agreed. We should avoid needless data duplication. I came to this schema looking specifically for whether it was okay for me to put some keys on only one element, and recommendations on which element. For example, crossing:markings=*, tactile_paving=*, and traffic_signals=*. AngryPen (talk) 23:40, 18 February 2026 (UTC)

Should we add tiers for footways not tagged otherwise (aka just highway=footway)

I think that we should add a section for footways that do not have any footway=* tags but are still footways (like a footpath inside of a park with no adjacent roads) to this document as these are still part of the pedestrian network and thus they should be considered. If we decide to consider them I would think that tagging for these ways would follow similar tiers as sidewalks, and we may be able to get away with just adding a note to the section with the tiers for sidewalks that mentions that non tagged footways also follow the same tiers. --Udarian (talk) 18:23, 9 March 2026 (UTC)

NB, it would be a good idea to recommend these be tagged footway=path otherwise it is not possible for mappers, tools and data consumers (including those implementing, validating and ingesting this PWG schema) to reliably distinguish between an actual footpath like these and merely a highway=footway that is missing more specific footway=* tag, that may well be a sidewalk or another type of footway. The latter is unfortunately quite common for sidewalks and other types of footways in the places I map, both higher and lower mapper density. Since first being documented in the beginning of 2025, it has seen rapid growth since then despite not yet being included as an official iD or JOSM preset (how most mappers typically add tags), and has already been apparently adopted by several data consumers including the popular OSMAnd as well as the AccèsLibre Mobilités schema for accessibility mapping of pedestrian infrastructure. CAM-Gerlach (talk) 18:54, 9 March 2026 (UTC)

I can see that, but from how I see it once the geometry of pedestrian features has reached silver or above it can mostly be assumed that highway=* without footway=* is the same as footway=path as by that point every other part of the pedestrian network would be separately mapped and tagged as necessary, so I am not fully certain it would be needed. --Udarian (talk) 19:34, 9 March 2026 (UTC)

Perhaps, but the wisdom of relying on unstated assumptions aside (which I would question), without an explicit footway=path tag there is no way for validators to know a particular untagged footway is reviewed and mapped at the PWG Silver Tier level, as right now there are no requirements for such and even if there were, you could make a similar argument for any other foo=no tag being implicit at a given tier, many of which are much more commonly the no value. Also, unlike those a correct and affirmative footway= classification is critical for determining which PWG schema requirements apply to the way in the first place, as it not only characterizes the way but classifies it. Given once this is incorporated into editor presets it should require no extra clicks over an unspecific footway (it would simply replace or supplement the existing "generic footway" option in editors), I don't see a particular downside of requiring it at PWG Bronze tier since it is a basic property of the footway and determines other requirements that may apply (though given it is still getting established in usage I would not reject an initial inclusion at Silver tier). CAM-Gerlach (talk) 20:23, 9 March 2026 (UTC)

Also I am unsure if footway=path fits for footways connecting buildings, like for example within a collage campus (full disclosure that is how I came to the idea to mention this here, I was analyzing the data around the collage campus I go to and realized that allot of the footways inside of there wouldn't fall under any tiers and think they should). You can also find a similar situation in amusement parks like the Disney parks where I don't think that footway=path fully fits for the footways within those. --Udarian (talk) 19:42, 9 March 2026 (UTC)

Per the opening sentence of the wiki definition of the tag, "The footway=path tag is used to designate footways that are intended for general pedestrian use but are not associated with a road or street," and later "Independent walking paths connecting different areas, without following the course of a road,", and that is also how it is described on the footway=* page ("Used for pedestrian paths not linked to roads."), so yup that would absolutely apply to that case. In fact, that's a major use case for them in my own primary mapping community (Blacksburg, VA/Virginia Tech)--historically, local mappers had tagged the many hundreds of pedestrian paths connecting the Virginia Tech campus were tagged highway=path (which is more typically used for trails and other recreational/informal paths, and for mixed-used paths specifically built for multiple transport modes) due at least in part to the lack of a suitably-specific footway=* tag at the time, which following a discussion with several local mappers (not initiated by me, in fact) we are now in the process of migrating to footway=path. Same would be the case for Disney, etc., these are "independent pedestrian paths connecting different areas not following the course of the road". CAM-Gerlach (talk) 20:23, 9 March 2026 (UTC)

Should we add tiers for staircases (aka highway=steps)

I think that we should add a section for staircases (highway=steps) as these are part of the pedestrian network and thus should be included in this document. From how I see the tiers would as follows:

• highway=steps
  • surface=*
  • incline=* up and down
  • incline=* in percentages
  • incline:across=*
  • lit=*
  • width=*
  • tactile_paving=*
  • tactile_paving:colour=*
  • handrail=*
  • handrail:(left|right|center)=*
  • step_count=*
  • ramp=*
  • platform_lift=*

We could also include flat_steps=* and level=* as these could be useful properties to map that are somewhat general, as for tiers I would say that both tags would be gold tier. step:height=* and step:length=* can also be added but those very much fall under the umbrella of micro mapping and I could see why others wouldn't want them in the schema, at least for now, these would obviously fall under diamond tier. These are just ideas for what could be tagged, Some of them like surface=*, incline=* and step_count=* feel like rather obvious inclusions as they would be rather useful for staircases but others not so much. The only one that I am unsure how exactly the right way to define it would be is tactile_paving=* as I could see it meaning across the whole way as it does with other pedestrian features mapped as ways but I can also see it only meaning on the edges of steps, something I have seen IRL.