Don't recommend "description=... sidewalk"

[Woazboat]

Hi, please don't recommend adding description=... sidewalk tags to OSM. That information is redundant as the other tags already specify that it's a sidewalk and the corresponding street can be figured out from the geometry (and the description tag isn't the proper place for that anyway).

https://www.opensidewalks.com/files/01_OpenSidewalksEditing.pdf

[nbolten]

Hi! Thanks for raising this issue!

The description tag is appropriate for any (short) additional information that is either not in the map or would be difficult or unreliable to infer. The OSM wiki uses the example of, "Muddy in wet weather" for a footway, for example; one could guess that surface=dirt might imply a muddy surface when wet, but there is value in allowing mappers to disambiguate.

As you note, a sidewalk-street association, along with the 'side of street' information, are candidates for being inferred. We are working on algorithms to do this as part of related work, though I'm not aware of any existing algorithms that are particularly reliable. An important case, in particular, is short ways - small subsegments of sidewalk broken up for differing widths, surfaces, etc. But, we may have missed something in our review of others' methods. Do you have any examples of a reliable, proven sidewalk(footway)-street-associating algorithm that uses OpenStreetMap data? I'd be keen to check it out.

In lieu of such a system, OSM is limited in the information it can communicate textually to a pedestrian about a sidewalk footway. Mainly, a sidewalk is (of course) semantically associated with a street ("the sidewalks on Main Street", e.g.) and this is how people describe sidewalks when having discussions. The addition of a direction allows for (usually) distinguishing one of two sidewalks. Unfortunately, there is not yet a relational primitive that explicitly associates a sidewalk way with a street way in OSM, an appealing way to infer this information reliably without guesswork.

So, my conclusion is currently two-fold, though I'd be interested in your feedback:

1. The description tag is important to keep in our schema regardless of what information is recommended to be placed within it. I don't think you're suggesting we don't use it, but I just want to be super clear on that.
2. Without a reliable way to infer street associations, we have to use the description tag to crowdsource a textual description of the sidewalk, which is entirely missing otherwise. I'm not aware of an existing method to infer this, but am happy to be informed!

[Woazboat]

I don't think you're suggesting we don't use it

That is actually what I'm suggesting. What you want to do here is create a semantic, machine-readable connection between a sidewalk and the associated street (which can then be presented to humans in an appropriate way via e.g. audio hints, textual display, coloring on a map, etc...). The description=* tag is intended for information that cannot clearly/easily be made machine readable (i.e. there's no easy way to encode it and there's no other way to infer it) but which is nevertheless useful information for humans. A freeform text field with no defined structure is not the appropriate scheme for your use case.
(Also, consider the case where there's already a different description present, such as the "Muddy in wet weather" you mentioned. What do you do then?)
The right way to encode this information would be via a relation or a tag such as (fictional example) associated_street=Main Street which has a clear structure and semantics and can be parsed by machines. (Of course that fictional associated_street=<street name> tag would not work with unnamed streets, which illustrates one of the complexities here that need to be considered.)

Unfortunately, there is not yet a relational primitive that explicitly associates a sidewalk way with a street way in OSM, an appealing way to infer this information reliably without guesswork.

There is, actually: https://wiki.openstreetmap.org/wiki/Relation:street (with an additional proposal that explicitly introduces a role for sidewalks https://wiki.openstreetmap.org/wiki/Proposed_features/Relation:street)
It's just not that widely used (yet?) because I guess so far people haven't found that many compelling use cases that justify the added complexity.
Of course alternatively ATYL applies https://wiki.openstreetmap.org/wiki/Any_tags_you_like or you could create a proposal https://wiki.openstreetmap.org/wiki/Proposal_process

Do you have any examples of a reliable, proven sidewalk(footway)-street-associating algorithm that uses OpenStreetMap data? I'd be keen to check it out.

I'm not familiar with the relevant tools, so unfortunately I can't help you there.

[nbolten]

(...) A freeform text field with no defined structure is not the appropriate scheme for your use case. (...)

Yes, exactly! We would much prefer to have an in-schema, machine-readable, semantic mapping between sidewalk(s) and street(s). The description field is what we felt stuck with after many conversations with OSM community members, including some fairly high-profile ones. Some of those high-profile members objected to the idea of mapping separate sidewalks at all, stating that it meant sacrificing street-association information! A few mentioned the possibility of using associatedStreet, but described this as an extension that would need to go through the proposal process (and many were against this use case).

description was a workaround for a lack of such a primitive, per our understanding.

The right way to encode this information would be via a relation or a tag such as (fictional example) associated_street=Main Street which has a clear structure and semantics and can be parsed by machines. (Of course that fictional associated_street= tag would not work with unnamed streets, which illustrates one of the complexities here that need to be considered.)

I don't think this would create a conserved, maintainable relationship between the sidewalk and street. It would make it possible to surface a street name when referring to a sidewalk (excellent!), but if we wanted to say what side of the street it was on (or ideally, get even more info about the street), we'd need to rely on guesswork again (name matching and spatial searches). Though just to be clear, I'm responding to the idea of an associated_street=<text> tag (which is undocumented and seems to be relatively unused), which is different than the associatedStreet relation. Having an inambiguous OSM relation between sidewalk and street ways could be conserved and maintainable.

There is, actually: https://wiki.openstreetmap.org/wiki/Relation:street (with an additional proposal that explicitly introduces a role for sidewalks https://wiki.openstreetmap.org/wiki/Proposed_features/Relation:street)
It's just not that widely used (yet?) because I guess so far people haven't found that many compelling use cases that justify the added complexity.

Thanks for the reminder of this relation! Most of my experience with street relations is the associatedStreet relation, which per my understanding is mostly used for addresses in France. We were generally discouraged from using any existing relations by the aforementioned OSM community members.

I just did some overpass searches to see how actively it was used (and exactly how it included sidewalks). There are a few thousand uses with a sidewalk role and a few hundred that include a sidewalk way under a different role and their use seems to be experimental - I didn't find any towns or neighborhoods that were all mapped with sidewalk-including street relation. Instead, it was usually one isolated streets or maybe a small cluster of 3-10. I checked the type=street relations in Western + Central Europe and would hand-wavily estimate that there's a roughly event split between relations with sidewalk members added 10 years ago, relations with sidewalk members added in the last few years, and relations with sidewalk members added within the last year. I'm not 100% sure what insight to take away from that, just that it somewhat confirms my thinking that this strategy is used experimentally/sporadically.

With that said, we are very interested in the idea of using this relation rather than putting the relevant data in the description tag and it's encouraging to see at least one community member is on board with it. Thanks for reminding us to look into it again!

Now we'd want to really dig in and see whether it's copacetic, in general, to add these relations. My interpretation of the existing, accepted type=street relation vs. the proposed version is that the accepted one is pretty generous about what can be included, saying that you can create any additional member roles as "[a]nything else that belongs to the street, but doesn't contain an address." So I would interpret the new proposal as a clarification on what role values should explicitly be included. My (optimistic) interpretation is a tentative green light on using the type=street relation to relate streets and sidewalks now as well as within the new proposal. But I should probably temper that optimism by checking in with more OSM community members, just in case.

I'm not familiar with the relevant tools, so unfortunately I can't help you there.

Totally fine, I misunderstood your idea of where unambiguously-associated street info could come from.

Please let us know if you have any contacts, resources, or further recommendations for building momentum on (or at least not stepping on toes with) the type=street relation with sidewalk members! And thanks again for the great feedback.

[Woazboat]

description was a workaround for a lack of such a primitive, per our understanding.

Using description=* in this way would go against the established guidelines for the tag (or at the very least stretching them) and would very likely not be supported by a large part of the OSM community. Misusing something else that's not intended for it to compensate for the perceived lack of other methods is not a good way to go.

Some of those high-profile members objected to the idea of mapping separate sidewalks at all

Different people have different opinions. Regardless, both styles (tagging sidewalk information on the main highway or tagging them separate) are valid and in use. Whether those objecting are high-profile community members or not doesn't really matter that much. In OSM fashion, what actually matters most is whether the local communities in the corresponding areas agree with the practice or not. (That is absolutely not to say that the opinions of other mappers, especially more experienced ones, should just be disregarded)

A few mentioned the possibility of using associatedStreet, but described this as an extension that would need to go through the proposal process

Yes, that's because the associatedStreet relation is only used to link houses with streets for addressing purposes and repurposing an existing tagging scheme with such a narrow scope for something else is not something that should be done without community consultation. That's a bit more delicate than a new tagging scheme that just doesn't get used in the worst case.

I don't think this would create a conserved, maintainable relationship between the sidewalk and street. It would make it possible to surface a street name when referring to a sidewalk (excellent!), but if we wanted to say what side of the street it was on (or ideally, get even more info about the street), we'd need to rely on guesswork again (name matching and spatial searches). Though just to be clear, I'm responding to the idea of an associated_street= tag (which is undocumented and seems to be relatively unused)

The associated_street=* tag was just an (as noted, fictional) example that I made up to illustrate the difference between repurposing an existing unstructured freeform tag (description) and a dedicated tagging scheme with defined structure and semantics. I'm definitely not suggesting that it should actually be used for this purpose because it obviously has a few issues (a lot of which it actually shares with your proposed use of the description tag).

We were generally discouraged from using any existing relations by the aforementioned OSM community members.

See above for why repurposing associatedStreet is problematic. The street relation doesn't have this problem as it was explicitly created for this use case.

I just did some overpass searches to see how actively it was used (and exactly how it included sidewalks). There are a few thousand uses with a sidewalk role and a few hundred that include a sidewalk way under a different role and their use seems to be experimental

The suggested role for sidewalks according to the street relation extension proposal is pedestrian, which has about ~18000 uses. (Although I question the need for specific roles here as the objects themselves already contain this information so it doesn't really need to be duplicated here. E.g. sidewalks can simply be found via the footway=sidewalk tag. Currently there are 14323 such sidewalk ways in street relations: overpass query)

I didn't find any towns or neighborhoods that were all mapped with sidewalk-including street relation.

Relatively few towns are consistently mapped with sidewalks in general, even fewer with sidewalks as separate ways. Finding one that consistently uses a relation which is not really used by any existing applications on top is not very realistic.

just that it somewhat confirms my thinking that this strategy is used experimentally/sporadically.

Yes, because there are/were no (or not enough) use cases why mappers would bother to add this increased complexity.

My interpretation of the existing, accepted type=street relation vs. the proposed version is that the accepted one is pretty generous about what can be included, saying that you can create any additional member roles as "[a]nything else that belongs to the street, but doesn't contain an address." So I would interpret the new proposal as a clarification on what role values should explicitly be included. My (optimistic) interpretation is a tentative green light on using the type=street relation to relate streets and sidewalks now as well as within the new proposal.

The existing street relation already allows you to add arbitrary objects associated with the street. As far as I understand it the new proposal mostly just introduces a new method to associate everything in an area with the street (in addition to the objects referenced in the relation), as well as explicitly define some roles for certain features.

Please let us know if you have any contacts, resources, or further recommendations for building momentum on (or at least not stepping on toes with) the type=street relation with sidewalk members!

I'd suggest contacting and working with the authors of the street relation proposal to ensure the semantics are properly defined and useable for sidewalks and working out other kinks by engaging with the community and requesting feedback about it. As for building momentum: good editor support and clear use cases (e.g. via an application or at least a demo that actually uses the tagging scheme for something useful) tend to incentivise mappers to actually use a tagging scheme. Stepping on toes can mostly be avoided by ensuring that those that are actually impacted by this (i.e. the actual local mappers that are going to have to work with it) are on board with this and by providing good documentation for your efforts.

[amandasaurus]

I don't know a lot of specifics here (having only read this issue), but I'm with @Woazboat here. OSM has a relation type for exactly this, relating other OSM objects together, and I think that's much more robust than freeform use of the description tag on the road.

[matkoniecz]

Please, at least do not claim that it is an OSM convention.

https://wiki.openstreetmap.org/wiki/Any_tags_you_like is a thing, technically it can be tagged this way...

But such use of description tag is not a standard or OSM convention and has no chance to scale up to millions of sidewalks.

[matkoniecz]

Do you have any examples of a reliable, proven sidewalk(footway)-street-associating algorithm that uses OpenStreetMap data?

I guess that you tried "match each part of way of sidewalk to the nearest road, respecting layer/bridge/tunnel info" and it was not good enough?

[1ec5]

At the least, such an algorithm would have to account for connectivity or barriers. Otherwise, you’d get plenty of edge cases, like where a sidewalk happens to run smack-dab in between a freeway and a surface street, but in reality there’s a wall separating the sidewalk from the freeway that takes up the same amount of space as the verge separating it from the surface street. Probably the most robust approach would essentially be a map-matching algorithm taking the sidewalk ways as input to match against the road network.

[1ec5]

This wiki page points out in passing that some mappers prefer to tag the sidewalk with the associated street’s name in name, skirting the issue of inventing a new key. The idea is that the sidewalk is just another carriageway of the road, so it should be named in common with the road. In my opinion, it’s more elegant than some of the other approaches that have been proposed over the years. And any relation scheme or algorithm for collecting carriageways of a road would then apply to the sidewalks too.

[nbolten]

To @Woazboat: thank you for your feedback, again! Where I've left out some of your responses, it's where I believe we are impicitly in relative agreement.

Using description=* in this way would go against the established guidelines for the tag (or at the very least stretching them) and would very likely not be supported by a large part of the OSM community.

The current document states this: A free form text field for describing a path. May be pre-encoded in relevant pedestrian paths to assist with routing instructing or investigation of map features. For example, a description of the sidewalk in relation to a nearby street may be a useful textual description, such as "NE of Main St." Can also be considered a flexible location to embed arbitrary information for specific use cases.. Can you please elaborate on how this is incompatible with current guidelines? We do not see the disconnect.

I would also like to clarify what the OpenSidewalks Schema is, as I can see that our documentation is not be clear on its relationship with OpenStreetMap, particularly when it comes to mapping recommendations. We definitely need to address that in our schema definition and other materials. The OpenSidewalks Schema is intended to be a nominally OpenStreetMap-compatible data schema, where nominally means that one can derive OpenSidewalks Schema data from a subset of OpenStreetMap data and one could generate OpenStreetMap-compatible data from a subset of OpenSidewalks Schema data. But other data producers and consumers are also possible. For example, we transform several open municipal datasets into OpenSidewalks Schema data - datasets that do have unambiguous, machine-readable street-sidewalk relations and direction-from-street data. We do end up putting that in the description field in order to maintain OSM compatibility, but it would never end up in OpenStreetMap without local approval + consent. This nominal compatibility creates the opportunity for mutual, consented data-sharing between communities and agencies responsible for the collection of these data, and to provide communities with greater input into these data collected "on their behalf", but that opportunity has not yet been realized: agency pedestrian data doesn't go into OpenStreetMap.

In other work, where we do have OpenStreetMap mapping recommendations, we do not actually provide a recommendation on what goes in the description tag (the screenshot is listed as an example of what people have mapped) and have only done so in collaboration with local communities. But that is useful data to keep when translating into the OpenSidewalks Schema, so of course the schema should reflect that and sets expectations for what information might be in that field.

Different people have different opinions. Regardless, both styles (tagging sidewalk information on the main highway or tagging them separate) are valid and in use. Whether those objecting are high-profile community members or not doesn't really matter that much. In OSM fashion, what actually matters most is whether the local communities in the corresponding areas agree with the practice or not. (That is absolutely not to say that the opinions of other mappers, especially more experienced ones, should just be disregarded)

The previous feedback we have received highlights some challenges to constructively resolving this question, however - and that's my motivation in bringing it up. Put yourself in our shoes! Statements offered up as objective ("there is already a street-sidewalk relation") contradict similarly vehement opinions from others in the community, including many with long-time investments in it. We're not surprised that there's disagreement in a community-driven effort, especially about data - so much passion is a great thing - but we need more context and specifics in order to provide our own feedback and make decisions.

(...) See above for why repurposing associatedStreet is problematic. The street relation doesn't have this problem as it was explicitly created for this use case.

Of course! I'm just supplying context so that you can see where we are coming from. I am surprised that this relation did not come up in such discussions.

The suggested role for sidewalks according to the street relation extension proposal is pedestrian, which has about ~18000 uses. (Although I question the need for specific roles here as the objects themselves already contain this information so it doesn't really need to be duplicated here. E.g. sidewalks can simply be found via the footway=sidewalk tag. Currently there are 14323 such sidewalk ways in street relations: overpass query)

Good to know that pedestrian is the proposed use case, as I had assumed this was related to highway=pedestrian. Though, the queries I used did not distinguish between roles. I used an approach in line with your thinking: people are adding sidewalks as members of the type=street relationship, so they're trying to say these are sidewalks of that street regardless of whether the role is pedestrian, sidewalk, or really anything else.

Relatively few towns are consistently mapped with sidewalks in general, even fewer with sidewalks as separate ways. Finding one that consistently uses a relation which is not really used by any existing applications on top is not very realistic.

Our groups needs to be able to answer these questions:

• Can we use this relation today as part of wider OSM mapping recommendations?

• If not, should we advocate for it?

• If we need to advocate for it, is it tested and in use or do we need to create a test area ourselves?

To me, the relation being used sporadically and experimentally helps us answer these questions. In order, the answers seem to be, (1) no, (2) probably (after learning more), and (3) we'd need to create a test area.

Yes, because there are/were no (or not enough) use cases why mappers would bother to add this increased complexity.

Can you clarify for us how you know this is the case?

I'd suggest contacting and working with the authors of the street relation proposal to ensure the semantics are properly defined and useable for sidewalks and working out other kinks by engaging with the community and requesting feedback about it. As for building momentum: good editor support and clear use cases (e.g. via an application or at least a demo that actually uses the tagging scheme for something useful) tend to incentivise mappers to actually use a tagging scheme. Stepping on toes can mostly be avoided by ensuring that those that are actually impacted by this (i.e. the actual local mappers that are going to have to work with it) are on board with this and by providing good documentation for your efforts.

Thank you for the recommendations!

[nbolten]

Hi @matkoniecz!

Please, at least do not claim that it is an OSM convention.

I am unsure what is meant by "OSM convention". So far as I can tell, the description tag is extremely vaguely defined, it doesn't have conventions outside of length (keep it short) and not having subjective statements. This is the entirety of the definition on the wiki:

The [description]()=* tag can be used to provide additional information about the related element to the end map user, possibly using a pop-up or similar. Text should be kept short; a few words or perhaps one to three sentences at most. Longer information can be provided by tagging a link to Wikipedia or other external website using [wikipedia](https://wiki.openstreetmap.org/wiki/Key:wikipedia)=*, [wikidata](https://wiki.openstreetmap.org/wiki/Key:wikidata)=*, [url](https://wiki.openstreetmap.org/wiki/Key:url)=* or [website](https://wiki.openstreetmap.org/wiki/Key:website)=*.

Use [note](https://wiki.openstreetmap.org/wiki/Key:note)=* for information which is for use by other mappers (for example a note indicating that the aerial imagery should not be believed or similar).

Never use [description]()=* to add advertising messages. Such spam can and should be removed as soon as spotted. The description should not include subjective evaluations, e.g. "the best restaurant in town", "modern, comfortable hotel, in the heart of the city".

Can you tell me where I can find more information on what the convention is or help me understand where I'm misinterpreting the wiki?

But such use of description tag is not a standard or OSM convention and has no chance to scale up to millions of sidewalks.

To clarify, we are not declaring that "this street in this direction" is a standard or OSM convention with description, just that this is where people have often placed additional path information, providing some examples. It is also possible I'm not understanding what is meant by convention.

I guess that you tried "match each part of way of sidewalk to the nearest road, respecting layer/bridge/tunnel info" and it was not good enough?

Yes, of course.

[matkoniecz]

it would never end up in OpenStreetMap without local approval + consent

Thanks for that! I admit that I was a bit confused and it looked to me like instructions to people editing OSM right now.

Statements offered up as objective ("there is already a street-sidewalk relation") contradict similarly vehement opinions from others in the community, including many with long-time investments in it.

Sadly, sidewalks and especially crossings are part of OSM tagging scheme with many outstanding serious issues in how they are tagged and some deeply held opinions how things should work (separately mapped sidewalks vs sidewalk tags are just the simplest example)

Can we use this relation today as part of wider OSM mapping recommendations?
If not, should we advocate for it?
If we need to advocate for it, is it tested and in use or do we need to create a test area ourselves?
In order, the answers seem to be, (1) no, (2) probably (after learning more), and (3) we'd need to create a test area.

I admit that I have an allergy to relations unless absolutely needed as they complicate editing. I would advise to create some set of example which are not solved by "just match to nearest matching road" and not solvable by using already existing tagging.

If you plan to experiment with it I would suggest doing it on some small scale area in place familiar to you (in general "I am local mapper and I map my surroundings" has much better impression that "I edit remotely from another continent")

I am unsure what is meant by "OSM convention".

I interpreted it as "typical use of tag in OSM".

Using description for systematic encoding of machine readable info of associated sidewalks is not a standard use of this tag.

description tag is a freeform field and you are proposing to use it with some rigid format and relying on it to process OSM data.

Note that description=chodnik Armii Krajowej could be used in Poland and description=overgrown paving stones is equally valid use.

You should not be surprised if someone will edit descriptions that you rely on (plan to rely on?) or retags it to say newly invented associated_road tag.

Can you tell me where I can find more information on what the convention is

OSM Wiki sometimes has some info, tagging mailing list and other https://wiki.openstreetmap.org/wiki/Contact_channels are also a good place if you want to ask people

I guess that you tried "match each part of way of sidewalk to the nearest road, respecting layer/bridge/tunnel info" and it was not good enough?

Yes, of course.

Do you have somewhere repo with set of cases/locations where such matching fails?

Are you familiar with A/B Street? That project had attempts or plans to handle such matching.

This wiki page points out in passing that some mappers prefer to tag the sidewalk with the associated street’s name in name, skirting the issue of inventing a new key. The idea is that the sidewalk is just another carriageway of the road, so it should be named in common with the road.

Though note that in many places this would be also met with a surprise...

Yes, because there are/were no (or not enough) use cases why mappers would bother to add this increased complexity.

Can you clarify for us how you know this is the case?

I can confirm this and I base it on my editing experience and involvement in tagging discussions but I am not going to claim that I am 100% neutral and without biases... For example I have above average dislike of relations.

[nbolten]

Thanks for the very helpful response, @matkoniecz! It clarified a lot of things for me and I really appreciate you taking the time to explain these things.

Thanks for that! I admit that I was a bot confused and it looked to me like instructions to people editing OSM right now.

I can definitely see how that's something we (mis)communicated and that our documentation needs fixing! I personally don't map the description tag in this way (I rarely map description at all) because I share the sentiment that these data need to be either inferred or directly mapped on appropriate primitives (tag/relations) to be reliable and maintainable. Though I should probably note that someone digging through my edit history will find some local edits of mine with such description tags because folks were putting it on the name tag (even worse!) and I didn't want to mass-delete their data. This thread is telling me that our group needs to surface and clarify these things:

• What's a mapping recommendation in OSM.

• What is passing data along from OSM and noting what that might look like.

• What is a field that may be derived from interpreting OSM and other data (I'm thinking the OSW schema should potentially have "street_name" and/or "street_side" and/or "street_id" fields to populate with non-OSM data).

Sadly, sidewalks and especially crossings are part of OSM tagging scheme with many outstanding serious issues in how they are tagged and some deeply held opinions how things should work (separately mapped sidewalks vs sidewalk tags are just the simplest example)

Yes, of course! We're not surprised that people will disagree with one another on a community-driven project, and with many valid positions to share with one another. It communicates, among other things, passion! I just want to surface that from our perspective, where we don't want to dismiss or reject perspectives, it means we (people working on OSW) need additional context and dialogue for making decisions on whether we're mapping/interpreting tags appropriately, etc.

I admit that I have an allergy to relations unless absolutely needed as they complicate editing. I would advise to create some set of example which are not solved by "just match to nearest matching road" and not solvable by using already existing tagging.

Yes, I 100% agree. Anyone advocating for including sidewalks in the type=street relation will need to make a thorough case, with examples, for the necessity of such a relation. I initially thought it was already approved in the less-specified version (since it isn't actually under a Proposed:* heading), but was mistaken. Since it's proposed, we'll want to bring everyone into a shared context and have good discussions around examples.

If you plan to experiment with it I would suggest doing it on some small scale area in place familiar to you (in general "I am local mapper and I map my surroundings" has much better impression that "I edit remotely from another continent")

Good recs! I would either do edits in my own neighborhood/city or work with some close collaborators in other cities (local OSM community members) with whom we communicate frequently.

I interpreted it as "typical use of tag in OSM".

Using description for systematic encoding of machine readable info of associated sidewalks is not a standard use of this tag.

I can see the problem of moving pre-existing machine-readable info into description, which is that we should ideally just use an actual machine-readable tagging schema. Where I run into uncertainty on this is that when mapping de-novo, I'd hypothesize that the majority of description tags could be reformulated in machine-readable info - so is everyone using the description tag running afoul? Examples:

• (from the wiki): description=Muddy in wet weather. One can imagine a machine-readable tag about surface conditions under wet weather, such as a (fictional) surface:wet=muddy tag.

• (from the wiki): [description:bicycle](https://wiki.openstreetmap.org/w/index.php?title=Key:description:bicycle&action=edit&redlink=1)=Ridable along most of the way but has sections with tree roots. One can imagine tagging the roots along the pathway itself using a (fictional) machine-readable tag.

• (in Warsaw, just for fun): description=rampa on a footway - someone wanted to say it was a ramp, but there's no good tag for saying a footway is a ramp so they used description. The wiki says to put an incline value on a footway to represent a ramp, though one could also imagine having a footway=ramp or similar tag in the future. Machine-readable info on a ramp.

• (near Warsaw): description=Chodnik znajdujący się pomiędzy blokiem Matejki 5a a sklepem Carrefour. (Google translate: "The sidewalk between the 5a Matejki block and the Carrefour store.") Possibly someone trying to fill in gaps similar to how we have done with municipal data / some local experiments.

• (in Berline): description=Alte Steinbrücke, jetzt nur für Fußgänger (Google translate: "Old stone bridge, now for pedestrians only"). There are already tags for being on a bridge and for designated pedestrian ways, would just need a way to encapsulate that it's on a certain bridge so that we can verify it's old and stone.

That might be too many examples, but hopefully what I mean is making sense.

description tag is a freeform field and you are proposing to use it with some rigid format and relying on it to process OSM data.

Ah, that may be a miscommunication on our part. We don't rely on any format at all, the idea is to just pass along the description tag from OSM, which as you say is a (short) free-form text field - or, if we have good data from a municipality, synthesize a description (which won't touch OSM) from it.

You should not be surprised if someone will edit descriptions that you rely on (plan to rely on?) or retags it to say newly invented associated_road tag.

We would be very happy to see people edit + retag any such descriptions that do exist!

OSM Wiki sometimes has some info, tagging mailing list and other https://wiki.openstreetmap.org/wiki/Contact_channels are also a good place if you want to ask people

My understanding, then, would be that to know whether you are using a tag against convention would be to review the wiki and then how the tag is used "in the wild", which includes talking to the handful of people on the mailing list (which has usually meant parsing several incompatible statements-of-fact, in my experience). But in that case, I'd say that writing something like, "A sidewalk on the Northeast side of 20th Street" matches convention based on the way I've seen description used. It's pretty similar to how that footway near Warsaw was tagged. More examples of the description tag, this time on footways near London:

• description = Ramp to tram stop
• description = footbridge linking all platforms
• description = Ramps down to subway
• description = The Broadway Hammersmith lower level
• description = Link to Greenway
• description = Part of the Celandine Route.
• description = Route around Northwick Park
• description = This footpath runs through the Bentalls Centre & is open when the centre is.

I'm sure there's discussion to be had about how correctly-mapped some of these examples are, but I am... pessimistic that I would come to any different conclusion about description=* based on these resources. Maybe the wiki should be updated?

Do you have somewhere repo with set of cases/locations where such matching fails?

I do not think that I do, my work on that was several years ago during early evaluation stages. I think it would make sense to prepare something like that for contributing to the type=street proposal.

In the meantime, I can give an example of where it will frequently fail: whenever two streets of different widths meet (let's say they all have sidewalks right at their boundaries and they meet are sharp-ish corners), a nearest-street algorithm will classify sidewalks that should be part of the wider street as part of the narrower street.

Another example: sidewalks tend to be mapped as centerline, so they're offset a bit from any parallel curb (so their distance from the street is 1/2 the street width + 1/2 the sidewalk width, roughly). Many people will start/end a sidewalk at the street boundary, however - so the distance from a sidewalk to a neighboring street will be only the 1/2 the street width portion. The sidewalk line is closer to an orthogonal street, all things equal.

Algorithms for reliably determining sidewalk associations will need to use more complex analyses. Probably things like this: street buffer searches, splitting/merging of sidewalk edges within a graph interpretation + street and intersection geometries, line similarity, sampling approaches comparing normals between points along a sidewalk and the nearest projection point on a street.

Are you familiar with A/B Street? That project had attempts or plans to handle such matching.

Yep! The A/B street dev was in Seattle for a while and we've met with them before! This is a good suggestion, though - we should check in and see if they have any cool new approaches.

[matkoniecz]

In general description tag is ranging from "not really used or useful" to "I had no idea how to tag this" and it rarely provides useful or systematic info (at least that is my opinion)

And I guess that [art of my reaction was skepticism that situation would be improved at all if such tagging would start being used (adding attempt to have some form of standardized info there would likely be problematic)

In the meantime, I can give an example of where it will frequently fail: whenever two streets of different widths meet (let's say they all have sidewalks right at their boundaries and they meet are sharp-ish corners), a nearest-street algorithm will classify sidewalks that should be part of the wider street as part of the narrower street.

Is it also failing unacceptably often when width of fully tagged road is taken into account? lanes/width/highway tags are obvious indicators. In other words, matching to road expanded into area rather than to the nearest centerline.

[nbolten]

Makes sense to me, @matkoniecz! I think we're in agreement that description, as it's used, has some issues and we should at least be careful with it and avoid using it as a store for machine-readable info.

Is it also failing unacceptably often when width of fully tagged road is taken into account? lanes/width/highway tags are obvious indicators. In other words, matching to road expanded into area rather than to the nearest centerline.

Well this example is in my head, so whether it fails is currently about whether my logic holds. I think that creating some code + repo for this would be helpful for the discourse in general, so I'll propose that to our group.

I'll still make an attempt with logic / rules alone, though! If I'm interpreting you correctly, the idea is that one could buffer street ways based on their properties, such as an actual width value or with heuristics based on lane count / highway class, then run 'nearest street buffer' on all sidewalk lines to infer an association. In terms of the two scenarios I presented:

1. Let's say there are no verges, it's just sidewalks next to streets. The parallel (correct) street will be the distance from the sidewalk centerline to the street surface outline in the best case scenario. The other (incorrect) street(s) will also be the distance the sidewalk centerline to the street surface, but the distance will be from a sidewalk endpoint to a street surface. All things the same except for street width, I think the associated street would be chosen in a somewhat unpredictable/random way that depends mostly on the geometry of the street corner.

2. When mappers extend their sidewalk(s) to the curb, it would still always choose the wrong street - the distance to the street outline would be 0 for the wrong street(s) and 1/2 the sidewalk width for the correct one.

The example in 1 also reminded me that verges and wide sidewalk surfaces make everything more complicated and introduce even more ways to choose the wrong street. It also reminded me that we can't expect that sidewalks will be split at intersection corners, so any associating algorithm would need to split the sidewalks up near intersections. For a worse-case example, some mappers add a sidewalk as a path extending all the way around a block (a single way!), so a shortest-distance association from raw data in a typical city block would pick 1 street for all 4 sidewalks, guaranteed to be wrong for 3 of them. If the pedestrian network is mapped appropriately (connect to the street by crossings), the data can be represented as a graph and split topologically at degree >= 3 nodes, but intersection corners may still have issues without a more semantic approach to splitting + associating them.

Basically, it's complicated. I think it can be done, but it'll take either some fancier algorithms or some (probably janky) heuristics with buffers used in other ways.

[1ec5]

some mappers add a sidewalk as a path extending all the way around a block (a single way!)

In fact, the San José sidewalk import unfortunately bent over backwards to ensure this was the case. It was one of the larger sidewalk imports in OSM’s history, so this would be a relevant case to consider. Routers are not so affected because there’s a many-to-many relationship between ways and edges in the routing graph anyways. But renderers don’t compute routing graphs, so associating sidewalks to streets would be more challenging.

At the least, such an algorithm would have to account for connectivity or barriers. Otherwise, you’d get plenty of edge cases, like where a sidewalk happens to run smack-dab in between a freeway and a surface street, but in reality there’s a wall separating the sidewalk from the freeway that takes up the same amount of space as the verge separating it from the surface street. Probably the most robust approach would essentially be a map-matching algorithm taking the sidewalk ways as input to match against the road network.

Some concrete examples from around Cincinnati, by no means exhaustive:

• This sidewalk along 3rd Street is a mere 10 feet (3 m) closer to 3rd Street than Fort Washington Way, a freeway separated by a tree line and retaining wall. A slightly less precise digitization of the freeway or sidewalk could easily result in the sidewalk getting matched to the freeway. An automated algorithm that doesn’t consider topology would need to exclude matches along freeways (highway=motorways), but some freeways do have sidewalks.
• This sidewalk along Lytle Street crosses above two different bores of the Lytle Tunnel but never connects directly to Lytle Street. An automated algorithm would need to consider keys such as bridge and tunnel, as well as the general shape of the sidewalk.
• This sidewalk along the upper deck of the Western Hills Viaduct is roughly equidistant to the lower deck of the Western Hills Viaduct. The lower deck happens to be slightly closer only because completely coincident ways are difficult to edit in JOSM and iD. An automated algorithm might require a matching layer key.
• This sidewalk straddles Columbia Parkway and U.S. Route 50. At times, it’s slightly closer to one; at other times, it’s slightly closer to the other. But in reality it occupies the entire space between the two roadways. It belongs to Columbia Parkway, but only because it connects to another way that more clearly hugs that expressway.
• This sidewalk along Court Street is only 3 feet (1 m) closer to Court Street than an unnamed parking lot aisle, close enough that typical 6-inch imagery offsets could be a factor. Urban and suburban parking lots also typically have sidewalks along their edges, but this sidewalk would need to be distinguished from one that only hugs the edge of the parking lot.

sidewalk=separate on the adjacent roadways would help to disambiguate some of these cases, but overall, these additional heuristics end up forming the rudiments of a map matching algorithm. It would be very cool if a renderer came with built-in routing functionality to enable such intelligent matching, but many way tags and relation types were designed to keep data consumers from having to take such a drastic step.

[matkoniecz]

so a shortest-distance association from raw data in a typical city block would pick 1 street for all 4 sidewalks, guaranteed to be wrong for 3 of them

I expected that matching would be done not with entire OSM objects (after all, someone can map single highway=footway line to represent kilometers of sidewalks from multiple roads but to split where "nearest road" changes.

(though I suspect that either way it would not always work)

I think that creating some code + repo for this would be helpful for the discourse in general, so I'll propose that to our group.

Feel free to ping me if that would be created!

[nbolten]

Hi everyone! And sorry for the delayed response, @matkoniecz! I really appreciate your feedback and help with making our schema better (in communication + content!).

I'm proposing two directions that will hopefully resolve this particular GitHub issue!

1. I'll make changes to the schema document itself to (1) remove references to 'sidewalk on X side of Y street' because this is definitely not communicating how we are actually proposing use of the description field (it's a holdover from a limited experiment and not an OSM tagging recommendation) and (2) further clarify where our schema overlaps with OSM tagging recommendations vs. being a separate 'superset' of OSM-compatible data, since our project does involve both and we're clearly not communicating that as well as we should be.
2. I'll make a new issue about sidewalk-street associations so that anyone interested can keep up this discussion! I'm personally finding it very helpful. e.g. I'd want to put some inference algorithm examples in that issue.

In terms of timeline, my plan for change 1 is to implement it, add a comment on this issue pinging people, keep this issue open until there's been 1 week of inactivity, then (reversibly) close the issue.

Thanks all for the great discussions and feedback!