Announcement / request for comments: naming sidewalks in Toronto

Both - but I was answering only here about routing.

If I’m walking from A to B, I always know where I am, because I’ve got something in my hand that says exactly where I am. I know where to go, because there’s a line on a map leading away from were I am now. The name of the road is basically irrelevant.

I can’t find that comment, I’m guessing it might be referring to the display of maps (web raster, web vector or Garmin) - in each case you’ll always get one name shown because the road will always have that name, which will be shown.

It routes on anything that is on the map that it thinks is routable :slight_smile: . That doesn’t include motorways, and by default it does not include trunk roads (though I ensure that those are pedestrian-routable on my maps if there is a sidewalk tag).

No - name isn’t a factor. various internal flags are manipulated here, but you don’t have a huge amount of control beyond “yes it will route pedestrians along here” or “no it won’t”.

1 Like

Ah I got it now. You’re using it for routing when in the field and prefer name-less directions (“turn left in 20 metres”). I’d like to have the text routing directions for reviewing ahead of time, and for that the name is much more useful.

I see it right in the section that you linked to ( mkgmap_style_ajt/transform_03.lua at master · SomeoneElseOSM/mkgmap_style_ajt · GitHub ):

I suspect that one major difference is that you’re using directions to route around something like this…

… whereas I’m finding my way around something like this:

(is this Colliergate or St Saviourgate or Whip-ma-whop-ma-gate? Does it really matter :slight_smile: )

3 Likes

This was brought to my attention from my country across the ocean and I’d like to inform you about the draft about naming streets - that includes sidewalks:
https://wiki.openstreetmap.org/wiki/Proposal:Relation:street
and actual implementation:
https://wiki.openstreetmap.org/wiki/Relation:street

Basically a street is legally not a line, but an area (likely your country as well) and inside that area there are roads, sidewalks, bikepath, parking spots, even trees.
So, you give name of the street to the relation and then you assign to the relation all the roads, sidepaths, cyclepaths and because of that street name is assigned to all we need.

Now, routing apps has to adapt to this solution, which might not happen soon enough for ppl here to be satisfied…
But just imagine the sheer amount of problems you gonna have naming sidewalks, at a two street highway. You gonna have sidewalk to the right, to the left and in the middle. At an intersection you gonna have a total mess.
image
see this roundabout and try to gues which cycle/footway is which and which.

Now if a cyclepath or a footway is built independetly and is given a name… then you tag it with a name and it might even happen part of it gonna be joined to the street relation, but please dont mistake a street name with a route-name(relation) or this named foot/cycleway.

We tag street name to a road only for simplicity, dont make simple things harder. Use the relation draft i have linked if you need to.

De-cluttering rendering has already been mentioned, but surely the ideal routing instructions would also different for those two cases (“Follow Foo Trail” vs. “Use the left sidewalk of Bar Street”).

5 Likes

I can’t tell you what to do in Montreal or Toronto, but in my eyes, duplicating the name of the street on parallel walkways or cycleways is not a good idea, and if it happened in my city I would certainly remove these names and have the backing of the local community for it. It is a crutch that you’re obviously implementing to overcome shortcomings in routing engines.

I think your point #3 in your original posting gives it away. Your argument is basically “I know this is wrong but it is easier to map things wrongly than to get routing engines to do the right thing” and/or “I know this is wrong but we’re doing the wrong thing elsewhere too”. This is not a good approach.

5 Likes

Honestly, the street is not just the traffic lane, it includes everything like the traffic lane, the sidewalk and the cycleway and the parking lane as well.

Currently, in OSM, only the traffic lane has the name=* tag. This doesn’t fully reflect the reality of what a street name represents to the public. When a street is named, that name often applies to the entire infrastructure - not just the driving surface.

I don’t think its wrong (why is it wrong anyway?), i think nobody is used that more ways with a different highway=* attribute can have the same name. Ignoring the renderer and the router, why is it wrong to give everything thats together the same name?

This approach may seems like a workaround for routing issues, but it also aligns with how streets are named and understood in real-world context.Technically it would probably better to put them together in a relation, but thats a whole other can of worms with a lot of complications.

I personally prefer street:name=* to is_sidepath:of:name=* because A) its universal applicable to more than just a sidepaths and B) its easier to remember.

In my opinion, it’s worth noting that applying name=* (or street:name=*) to sidewalks or cycleways is not necessarily “wrong”. It’s simply one way to interpret and tag the shared elements of the public right-of-way.

5 Likes

No it isn’t. The pavement (or cycle track, or whatever) is as much as part of the street as the motor traffic lanes, and has the same name, therefore it should be tagged as such.

In this example, how can you possibly say that the motor lanes are “Victoria Embankment” whereas the cycle track isn’t? Your argument is enormously motor-centric.

4 Likes

Adding names to things that aren’t its name is harmful to data consumers. Please don’t do it. You’re optimizing tagging for one specific type of data consumer. I care very much about only including named things in my software, and this kind of tagging is a problem for me. Whereas, other tagging like street:name is just fine and dandy.

6 Likes

I have actually registered walk.travel but haven’t done anything with it yet!

2 Likes

Yes, and I am not against combining various lanes for various types of traffic in a parent relation to make it clear that these are all the same thing with the same name, or let them refer to one another in other ways. I am, however, very much against suggesting that there are different things that all (independently) carry this name. That is the crutch I am speaking of. And Jarek is right in saying that we already suggest that there are 15 so-and-so-streets in the village just because so-and-so-street changes between cobblestone and asphalt all the time and the bus branches off somewhere in the middle. But the fact that something is somewhat shit in OSM should never be a license to add more things that are somewhat shit.

3 Likes

In a North American context, one typically distinguishes between the street and the overall streetscape. Everything between the curbs or verges – traffic lanes, street parking stalls, crosswalks, bike lanes, shoulders, even pedestrian lanes – would be considered part of the street. By contrast, a sidewalk, shared use sidepath, or median greenway lie within the corridor but not within the street. (COVID-era outdoor dining spaces can be either, depending on the physical location.)

This can have implications for guidance instructions. Most pedestrian routing profiles currently say things like, “Turn left onto name.” Ideally, the router would reserve that phrasing for when the pedestrian needs to literally share the road with cars. For a more typical sidewalk, a better phrase would be, “Turn left and follow name.”

The word “follow” is doing some work here: it’s the same word a router would ideally use when telling a motorist to follow the signs for a route instead of enumerating the specific turns. In both cases, the “follow” instruction is an abstraction over the routing network.

The biggest problem with pedestrian guidance is that it fails to abstract away the nitty-gritty details of individual routing edges in favor of the overall corridors you’re supposed to follow. The lack of street names is just a symptom of this shortcoming. A big reason is that many routing engines predate the practice of mapping sidewalks as separate ways, so this practice wasn’t considered in the original design. Your router might be more nimble than that; I don’t know.

In a previous job, I supported a team based in Toronto that was developing a wearable navigation device. It lacked a screen or had a very tiny screen, so it relied entirely on voice guidance. The granularity was problematic enough that they ended up configuring their application to ask Valhalla for pedestrian routes that avoid sidewalks like the plague. (This is a publicly documented option that the FOSSGIS profile on osm.org uses too, but not as aggressively.) The user was expected to understand that any reference to the street actually referred to the sidewalk. Street names might’ve enriched the default routes over sidewalks, but when “Turn left onto name,” could be referring to a tiny finagle in the sidewalk rather than a real street intersection, the result can be very confusing.

Wait. Are you saying that the late, great Kirsty Maccoll should have actually sung “Walking down a sidewalk parallel to Madison”?

1 Like

No, more like “Dancing in the middle of Madison.” Hey I’m dancin’ here!

1 Like

better try tag a name for this one:

and this one

and countless other sidewalks

I also asked in my example how ppl would name em there and noone wants to? ;]

Personally (as person who never was in Toronto and maybe never will) I want to say that it looks like an incorrect tagging to force specific behaviour in a router.

then it really should not have a name tag

  1. each highway= here represents a separate carriageway, not a separate highway - in the same as dual carriageway is represented by two highway= lanes

  2. at least in my corner of world there is consensus that small traffic islands are not a good reason to split it into two carriageways (similarly, flexible bollard between lanes on approach to pedestrian crossing is not reason to consider them separate carriageways)

have you tried at least requesting support? Note that support is more likely for more widely used tags

(maybe someone tried this? in this case mentioning this and linking relevant issues may be indicating it is a real problem. Also, if someone really cares about it - then writing PR or funding one may be also a solution, though definitely not a one accessible to all)

how you would assign names in case like this one?

3 Likes

Will a pedestrian router interpret that as: There are two carriageways to cross instead of one with a traffic island? First will make the crossing more costly, second will make it less so, at least in my experience as a pedestrian.

In my jurisdiction, the sidewalk is the part of the street reserved for pedestrian traffic. Pedestrians are obliged to use the sidewalk, if the street has one. There is only a limited number of reasons to not use the sidewalk and use the carriageway instead, some of them mandatory :wink: It even is impossible to allow bicycles on sidewalks. If the administration wants to allow them, they have to declare the sidewalk to be a footway instead and plant signs saying so.

PS: When carriageway and sidewalk (de jure lanes of a street) are split, the only way to map the name correctly would be a relation. But I am a bit upset by the consequence: Does highway=residential stop mapping a street and starts to map solely the carriageway then?

Sorry, where does “you can give sidewalks a name” imply “you must give every sidewalk a name”?

3 Likes