I understand the lack of faith in pedestrian routers when it comes to automatically inferring street names. I’ve been bandying about map matching as a solution to this problem for almost as long as others have insisted that routers can simply figure out which side of the street you’re on and call that a sidewalk, so certainly my claim can sound fantastical too.
Earlier this year when we debated Toronto’s sidewalk names, I timeboxed a few hours to toy around with map matching in Valhalla. Sidewalk Sidekick works by fetching an ordinary pedestrian route, feeding its geometry back into a map-matching utility for motorists, then collating the names in the response with the original route’s unnamed steps. Map matching isn’t new to navigation systems. For example, the Mapbox Navigation SDK uses it to indicate which street you’re currently traveling along. The only unusual aspect is intentionally matching across two different modes of transportation, something that developers usually do by mistake or against their will.
The code is poorly documented and the demo is buggy, but at least it is able to enrich a fair number of sidewalks with parallel street names, even across the diverse intersection configurations and street corner mapping styles here in San José. Honestly, getting the street name problem out of the way only lays bare some even bigger problems with pedestrian guidance. There are so many situations that need a big rethink for pedestrians, regardless of whether sidewalks and crosswalks are mapped as ways.
I would hope an application never has to orchestrate router calls manually like I did. Doubling or tripling the number of requests to the router could easily rack up outrageous fees with a commercial service as the user improvises and gets rerouted. Doing find and replace on text instructions is poor form. Valhalla should come up with the names on its own. I point to this experiment only to show that the router already has much of the information it needs internally to improve guidance instructions on a time scale shorter than the heat death of the Solar System. This would be useful whether or not mappers in one city or another go through the trouble of manually naming each sidewalk.
I looked at it once - as a PostGIS-based preprocessing step (i.e. before osrm-extract) rather than a postprocessing step, because why would I want to slow down my response times by 5x. It was moderately easy to get names for long pavements using proximity queries and comparing bearings, but started getting very messy for little footway sections at crossing islands, linking paths at junctions, and so on. Effectively the results weren’t really usable for this reason.
Riverbank-style area-plus-centrelines mapping is arguably the way to go here (i.e. a named polygon enclosing road, sidewalk and any other highway area). But until that happens then naming footpaths makes sense to me.
It sounds like you might’ve done a nearest-neighbor search per coordinate. I can see how that would get foiled by crossing islands and such. Map matching is more resilient to those issues because it considers the previous and subsequent points topologically. For reference, Mapbox integrated on-device map matching into their mobile navigation SDK primarily in order to tell whether the user’s current location is on the upper or lower deck of a bridge, based on how they got there. If anything, Sidewalk Sidekick is a little too aggressive at naming little jogs to the left or right after the streets that they technically parallel.
The map matching utilities in OSRM and Valhalla are highly optimized up to a certain number of coordinates. Kicking off this separate request does at least double the total completion time, but I believe there would be less overhead if Valhalla were to integrate the two steps in a single request. Precomputing all the names might make more sense with a router like OSRM than one like Valhalla that defers so much to request time anyways.
From what I’ve seen, junctions get very messy, but it has little to do with whether the individual steps are named or unnamed. The router isn’t collapsing complex junctions or eliding trivial maneuvers like it does for car directions.
Area routing is definitely valuable, but whether it’s appropriate for conventional streets would depend on the region and personal preference. I don’t think it should be a global default for determining the route geometry, but name enrichment can always take more liberties, as I’m doing here.
Not per co-ordinate. I forget the exact details but it was a proximity search on aggregated geometries grouped by name and using bearings to look for stuff that ran vaguely parallel.
Map matching via a routing engine is an interesting approach but is much more computationally expensive. One part of the c.t preprocessing pipeline requires matching up external datasets with OSM data. For Europe and AU/NZ that’s done via PostGIS proximity searches; for the US it’s done via OSRM map matching. The OSRM processes run fully multi-threaded but still take 12 hours to do something that takes the other regions about 20 minutes single-threaded.
Yes, I think there will always be a need to explicitly record the name of the parallel street in at least some cases, even if routers come up with a reasonably performant, reliable inference mechanism. Of the schemes for explicitly recording the name of the parallel street, this is the one I’d personally favor for its simplicity, though the Valhalla developers seem to desire something similar to associatedStreet relations.
Map matching the entire road network is expensive, but I don’t think this use case necessarily needs comprehensive conflation upfront. I’m also not sure if it would really work as well as an on-demand mechanism that has more context about the route that the user is taking, but that could depend on how the walkways are segmented in the graph.
@Minh_Nguyen For what it’s worth, I’ve been doing some more cleanup recently of a bunch of the older OpenSidewalks-related changesets and getting rid of the name= (OSM: 173027592) and description= (OSM: 173072497) tags on sidewalks. Still have more to do, of course, which I work on as time permits.
We (TCAT/OSW) don’t necessarily have a solid recommendation on how to associate sidewalks and roadways. We now recommend against tagging name=* or description= to indicate street-name association of sidepaths.
Personally, I lean towards street:name=, but we’ll see. The whole is_sidepath:of:name=* proposal is nicely structured but without the main editors hiding that behind a pretty UI, I would expect most people to find that tagging scheme unintuitive and unwieldy.
