I wanted to share some analysis on a currently undefined part of the PWG Schema (Silver Tier specifically) that I originally posted on the OSM-US Slack. Note that this was discussed previously on the OSM forum, but the analysis here was conducted independently before reading that to.

The key question here: What footway= type, other tags and geometry (separate way from the incoming sidewalk or not) should be specified for the connector ways between the sidewalk centerline and curb nodes?

Currently, the page states only “highway=? + ?=?”; its hard to see how highway= could be anything but highway=footway as nothing else seems more suitable and inventing a new highway type would be a major backward-compat break for little benefit; therefore, the decision then would be what footway=* tag to use.

Survey of options

Surveying the possible options (with pros and cons):

• A. (No tag): No footway=* tag at all (+) What OpenSidewalks schema does (albeit developed before footway=path existed) (–) Regresses the status quo and re-introduces the ambiguity solved by footway=path giving every footway an explicit type
• B. Path: footway=path (++) Avoids re-introducing the highly-ambiguous category of footways intentionally tagged without footway=* as in option A (–) Arguably inconsistent with the existing common usage of highway=path to map footways not associated with a road or street (i.e. the definition of sidewalks)
• C. Sidewalk: footway=sidewalk (+) Physically part of the sidewalk and as associated as it with the carriageway (+) Current de-facto standard practice for connectors in the cities I checked (besides the OS-mapped Seattle) (+) Easiest to map (+) Consistent tagging and segmenting between Bronze and Silver tier (+) Makes tagging and geometry simpler and more consistent between crossings where the sidewalk centerline by any definition continues all the way to the curb (driveways, intersections where only one street has a sidewalk or crosswalk) vs. turns a corner (intersections with sidewalks/crosswalk in multiple directions) (+) Conceptually, the the centerline of each given way’s sidewalk_ could be plausibly considered to continue to the kerb, if the sidewalk way is thought of as belonging to the street rather than the block, as indeed is how they are drawn in OSM (?) Optionally allows the connector to be part of the sidewalk way, simplifying mapping but could in theory increase complexity for consumers (-) Not (always) on the sidewalk centerline (per OpenSidewalks definition)
• D. Link: footway=link (+) Conceptually somewhat similar to the purpose of the existing tag (-) But quite distinct from the initial and most common usecase of this tag (-) Pedestrian footway infrastructure is (typically) physically present (–) Link primarily for routers vs. connectors important for renders as well and should always explicitly draw ways as connected
• E. Crossing: footway=crossing (++) Easy to map (-) Doesn’t split the way between the kerb and the crossing (–) Not actually part of the crossing (possibly a11y issue?)
• F. footway=Connector: New explicit footway=* value, e.g. footway=connector (++) Most unambiguous and expressive alternative (+) Mostly backward-compatible with existing data consumers (should be treated as a plain footway by tools that don’t recognize it) (+) Could enable better validation tooling and new options for future data users (-) Needs a compelling benefit to justify the extra work to map and break from existing mapping practice (-) Requires editor preset support and mapper education for widespread usage (–) Requires new tag value and migration to it

Commentary

After a holistic evaluation of the options, some commentary:

• link seems pretty uncontroversally inferior to the other options and can be discarded [Post-facto, I was surprised to see a small but vocal minority advocating for it for what seemed to be to be mostly-theoretical topological reasons]
• path seems strictly inferior to sidewalk in that given the main objection to each is not satisfying the category definition, path is by any reasonable definition further away than sidewalk and thus the former can be discarded
• (No tag) re-introduces the same fundamental ambiguity problem for all unclassifed footways that highway=path solved, which is either sufficient to likewise motivate a new tag (connector), or a strictly more serious and broader ambiguity than any conceptual distinction with sidewalk, and thus can be discarded in favor of those options
• crossing is easy to map, but isn’t really correct since the curb cut is not part of the crossing and shares properties with the sidewalk instead. This may also have a11y implications, more so than the other options.
• connector (or a similar new tag) is attractive to the purist in me, but its unclear that the conceptual advantages outweigh the practical (and conceptual) benefits of just sticking with sidewalk. However, it seems the least suboptimal of the alternatives besides sidewalk.
• sidewalk managed to overcome my considerable initial skepticism and emerge at least in my analysis above with some distinct advantages over other options and relatively few downsides. Likewise, it seems a top choice to consider.

Conclusion

My take: Seems to me that the overall most practical, efficient, simple and consistent solution with the fewest practical downsides is to simply follow existing de-facto practice and tag them as footway=sidewalk, as this is the closest and (at least anecdotally ) by far the most widely-used footway=* value (including counting no footway set) for way segments that extended to a kerb node and otherwise followed Silver Tier topology in current mainstream tagging practice in all the cities and places I checked (aside from the OpenSidewalks-mapped parts of Seattle)—NYC, Chicago, Washington DC, San Jose, and Blacksburg, Virginia, to name a few, checked via Overpass queries for kerbs and footways not tagged sidewalks in close proximity, as well as manual browsing and spot checks.

If the concrete benefits to tagging connectors specially is enough to motivate a new footway=* value over just using sidewalk, perhaps a new footway=connector tag could be introduced that experienced sidewalk mappers and PWG/third party presets and validators can start using now as a further refinement at the Gold level, while allowing them to be tagged footway=sidewalk at the Silver level. This would mitigate most of the mentioned downsides of introducing a new connector value vs. the existing sidewalk for everyday mappers and quicker/easier mapping, while still offering the precise tagging to sidewalk specialists well versed in the schema. Later, once editor if editor support, awareness and support for connector becomes widespread enough, Silver could be upgraded to require it in a future standard revision.

Edit: One option shared post-facto with me was footway=sidewalk sidewalk=<connector>—that has the appeal of being a further refinement of the current de-facto convention of footway=sidewalk, inheriting most of its benefits and fitting much more seamlessly into the idea of making it e.g. a Gold-tier or future/expert enhancement while also providing nearly all the advantages of a separate tag. This seems like a compelling “best of both worlds” option—go with sidewalk but also propose a further tag refinement for detailed micromapping and applications that need this to be tagged separately. The only real downside I can think of is overloading the existing sidewalk tag used for carriageways, but this could be at least partially mitigated by the PWG schema favoring exclusive use of sidewalk:<side> in all cases (if it is decided to go ahead with that).