The is_sidepath scheme was designed for exactly the kind of purposes you are facing right now @TaskarCenterAtUW. The proposal has recently been discussed in the community and has been met with controversy. Essentially, it tries to provide a way to express relational information through tags. However, it might be better to use a different syntax for this, e.g. something like related and related:name. Then this kind of “tagging relation” could be applied to other things like linkings between shops and their entrances, linking a roadside parking bay to its street, etc.
The core problem is that relations (as an OSM data element) in their current form are barely/practically not suitable for grouping streets and their adjacent sidepaths, because relations are difficult/practically not usable for non-experts, and there are hardly any possibilities to systematically check and maintain the data. (We are talking about streets that exist practically everywhere - so most OSM contributors would need to be able to create street relations, check them for completeness, integrity, recognise problems with the relation, etc. - this is an utopian vision for the foreseeable future).
In my opinion, a form of “tagging relation” as described above enables exactly the goals you mentioned:
- offer text or audible turn-by-turn directions for pedestrians (using the
related:name, or the proposedis_sidepath:of:name- but this indeed has an awkward syntax
) - account for presence/absence of pedestrian structure (you better need to do this by correct tagging on the street centerline, e.g.
sidewalk:left=no,sidewalk:right=separate!) - applications should actually be able to solve geometrically quite easily the side and direction of the sidewalk related to “it’s” street, if they know for sure that the sidewalk is located next to the street because it’s tagged according to a “relational tagging scheme”.
So we should continue to follow this issue in order to find solutions.