description= is not reliable, and rel is more complicated. I love name= myself. It is simple, will likely be supported almost everywhere, and is consistent with other parallel road features. (eg divided roads, frontage roadways, and bridges or tunnels) Renderers can choose not to show name= on footway=sidewalk.
yes, in Italy we came to similar conclusions, relations had also been discussed but were seen as not necessary and too complex. The same issue as with sidewalks also applies to cycleways along roads.
but how would that proposal further identify a sidepath’s (1) orientation viz-a-viz the associated road (northeast sidewalk of… south sidewalk of…)
this information is already in the data (geometrically), although using it requires understanding which highway a sidewalk belongs to (e.g. with several parallel carriageways and a sidewalk in between it may not always be clear).
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 proposed is_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.
I was thinking from the perspective of a sidewalk / routing on sidewalk lines: For a direction like “Use the Northeast sidewalk of Eaton Street” [or, in OSM language, e.g. “Use the sidewalk on the right of Eaton Street in OSM line direction”] when routing is happening on a sidewalk grid, the sidewalk segment has to calculate whether it is on the left or right side of the street? Assuming there are sidewalks on both sides of the street.
Not sure if I follow. Your last statement about the usefulness of is_sidepath (and similar) was made under the presumption that the geometry between footways and roads need to be analyzed in order to relate them to each other.
Both is_sidepath and sidewalk:right=separate are indicators for that the footway and road are not incidentally next to each other but are related to each other (i.e. one is a sidewalk of the other).
Now, since resolving such geometric relatonships (for all roads, all sidewalks) is expensive, I expect such things to be done by data users in a preprocessing step so that in the end, the relation to the street is already there when the data is actually used.
So the preprocessing algorithm would be “relate the next footway you find right of this road as sidewalk to this road”.
@kubahahaha – If I understand you correctly, I believe that particular sidewalk example you included would just be segmented at the corner in order to make its association identifiable (one segment with Wiersbowa street, the other with Barska street)
Yes it would be required to associate it with named streets.
But I believe it shouldn’t be done on OSM side. With current data model I think we shouldn’t require to create a lot of short ways for some virtual assignments, as we are not doing it for routers right now - in my previous example router has to tell you to turn left even if you are walking along single way.
I prefer to map sidewalk ways in alignment with a single named street because the sidewalk is conceptually part of the street. If I walk down North Union Street and turn left on Grant Street, I’m on a new street now. I don’t think of myself as being on the same sidewalk that has taken a turn around a corner.
Here multiple sidewalks around several blocks have been mapped as a single way. This is fine for a first pass, but it doesn’t seem like an ideal end state. I’ll probably break this up into separate segments along each street at some point.
in the past i went with just name on the sidewalk as it was implied as being possible correct at some point, but people weren’t happy about it. Though now looking I missed undoing it on some roads in my town.
Had it that way for 4 years on a good number of sidewalks around town, I really want to make pedestrian/bike routing work well and really needs to be a way to mark the sidewalk has that name or belongs to that street. Now thinking about it more I am still unsure if undoing it was right, but people told me it was wrong so i changed it.
That is quite good idea actually. As an added benefit: most duplicated properties of roadways (name, ref, surface etc.) can be moved to it and everything else that’s different can be on the way (turn:lanes, lanes etc.).
This does not work in practice and leads to constantly broken and incomplete relations.
It is not without reason that we in Germany (known for precise work ) have deleted in 2019 all associatedStreet relations. Discussion in Germany (old Forum)
Sometimes OSM way with sidewalk is not related to single street eg. here, I think sometimes it may be impossible to identify related street.
but in this case it can be related to the nearby streets (and must be split, what could be a preprocessing step). In other cases, going by 2-dimensional proximity, there will be detections of related streets where there isn’t such relation in the real world (e.g. because there is a retaining wall between the sidewalk and the road and both are vertically distant)
Do you have an empiric evaluation on specific wishes posted by those travelers with disabilities to the project of yours? I only can imagine, people with limited eyesight might want something different than people in mobility scooters e.g.
Of course, sensible directions sure is something that also people without any disabilities certainly will appreciate.
I’m recommending them, but there’s tags like object:street to tag the street name the object is next or closest to. Although obviously adding the tag to a bunch of sidewalks would be less then ideal. But it is an option. I think there are a couple of similar tags to, but I can’t find them right now for some reason. They are out there though. Perhaps something like destination:street?
Generally those using wheelchairs or scooters need an angled kerb to move from the street to a raised sidewalk. Blind pedestrians are assisted by textured surfaces that indicate things like the sidewalk’s outside edge or other transitions such as street crossings. Using high contrast colored material to create the textured area would make them visible to those with low or otherwise impaired vision.
The wiki for footway=sidewalk has recently been updated to add the assertion that “The name=* tag should not represent the associated street’s name.”
Naming sidewalks may not be the most elegant solution, but while the proposal including is_sidepath:of:name=* is still at the RFC stage, what else is there to help routing software produce pedestrian directions which include street names?
I don’t have a view one way or the other** but I can see that you’re already talking to them about it, so hopefully some sort of discussion will come out of that.
Maybe they should reply here to put their point of view?
** except that the wiki can be prone to show only the view of the last person who edited it, rather than a consensus. Some wiki editors are great at avoiding this problem, some not.
)
) have deleted in 2019 all associatedStreet relations.