The two extremes are not the only possible route profiles for this theoretical router. I would expect arbitrary crossing to have an associated penalty. We already see some routers distinguish between walking and hiking and some allow you to more strongly prefer flatter routes. You may also want a version that ordinarily permits steps, but not if there is no handrail or only allows them if there are fewer than a set number or steps before the landing. You may also decide you’re only going to allow crossings where parking is prohibited for better visibility. There are any number of scenarios you can come up with, most still have a better shot at a successful implementation if you’re treating sidewalks separated by not much more than a kerb as tags on the road they’re connected to.
If it’s planning a massive detour then it’s not giving a reasonable estimate of the time. There is also no guarantee that the detour is shorten-able on the fly. It may divert you down longer streets instead.
There is no situation I’m aware of in which a router needs to know that it can hop between pavements if crossings are mapped on either end of a road and around any junctions or paths that connect to the sidewalk.
Hmm
Crossings tend to only exist where the road meets a give way
Every trip I make involves crossing a road which is 700m long, with a crossing at each end. Whilst the T junctions have unmarked crossings with lowered kerbs there are no crossings over the main road at these points.
Are you really saying its reasonable for a router to send a pedestrian on up to a 700m diversion to get to the bus stop on the other side of the road or to continue on a road offset by 50m?
That reminds me of: There are two kinds of routing: Planning a trip and Walking a trip. In case of walking, the router needs to keep track of exactly where on the (planned) itinerary you are. And adjust instructions if you shortened the trail. In other words, it needs to do some kind of map matching, by using any kind of sensors available. GPS notoriously bad in tight urban surroundings, information from acceleration perhaps, integrating camera, &c? A bit like dead reckoning … Map matching your very location on three pathways (2×pavement, 1×carriageway) easier than on a single “street”?
In the end, I guess the “adding more detail to the map” faction will win. As a side effect, the data will get less useful for lots of people, and they will fight that with the means available, i.e. add even more “detail”, that is imaginary footpaths. I suggest to go two-dimensional and map a “parking” area there, it is clearly signed You do not even have to know the location, this can be achieved fully from aerials.
I think it’s clear from this thread that opinions differ on the general usefulness of separate sidewalk mapping, but I also think most people would agree that there are some situations where it’s adding important extra detail. There are also lots of mappers that like to add separate sidewalks. So I think those developing routers need to think about how to handle these cases as best as they can.
More importantly, if we accept that separate sidewalk mapping is going to happen (at least in some places), I’d like to see some clear guidelines developed for how separate sidewalks can/should be mapped well if they’re going to be mapped (e.g. in terms of adding extra tags to the sidewalks and/or parent roads, and ensuring that links/crossings are added). This would hopefully give us something to point errant mappers to, something for those wanting to make the map better to refer to, and ultimately in order to make life easier for developers and downstream users of routing software.
I’ve completed my attempt at following my above ”permeability” approach to part of Manchester City Centre, here. The changes have been made between Oxford Street, Portland Street, London Road/Piccadilly and Mancunian way (an area I know pretty well).
Notes:
I was relatively conservative with what I considered to be “permeable”. An example would be Auburn Street, which is easy to cross at any point but also forms part of the A6 nonsense routing and can see pretty heavy traffic.
All pavement and crossing ways were labelled with the road they are a part of. Crossings at the end of roads or across roads were not named.
Pavement ways were connected at junctions so that they maintained the flow of the road (previously most crossings involved walking a little bit up another road to cross, and a little bit back down that road to rejoin the road you’re working along).
Probably 10-15% of pavement ways were simply made up and did not exist, which was frustrating. Tagging was also all over the place.
This seems to have greatly improved the accuracy of the map, as reflected in the routing. Previously we had this set of directions for this route:
This still has the “driveway problem”, as well as the router not noting that Brook Street turns into Princess Street part-way along the route - but this is the router rather than the map. This can also be cleaned up further at either end, which I might attempt tonight.
Otherwise, I’m going to stop for the weekend before considering whether I want to carry on with this work, partly so that the local community can have a chance to digest it and partly because as I’ve worked on this I have become more convinced that mapping separate ways on most UK roads makes the map less accurate (although definitely more detailed).
I understand that the routers don’t take advantage of pavement tags all that extensively right now, but I think that mapping related components with a single way (plus appropriate tags) makes for a more accurate map - as well as allowing routers to give more options for routing (e.g. not to cross until it meets a crossing node, even one of a specific type). Again, I could be persuaded of this if there’s information out there about why routers don’t/can’t do this (feel free to signpost talks/blog posts) and ultimately I don’t really need to be persuaded if the community moves decisively against integrated pavements - but hopefully this has been a little bit useful in moving the conversation forward, at least.
As long as crossings are mapped at the ends of the roads and around any junctions to the pavement or the road then the router would just tell pedestrians to cross when they enter the road to the correct side for the bus stop. I don’t know why a pedestrian would want to route from one side of a street to a bus stop on the other side and I assume a pedestrian would just ignore it if the router told them to walk all the way to the end to cross.
Also it should be possible for routers to cross without explicitly marked crossings having done some testing. It’s not as efficient but it’s certainly possible. Tags to help routers know a road is cross-able by pedestrians at any point would probably help. Maybe even adding an association between the sidewalk and the road to help with the efficiency of the routing.
As it stands I can only think of weird edge cases that I can’t think of a justification anyone would have for routing like that. And even those edge cases your average pedestrian would just ignore. The benefits of separate sidewalks far outweigh any drawbacks caused by these edge cases.
That, alas, isn’t always an option. Imagine if I’m deciding to walk from wherever I am to one of two railway stations - I need an accurate estimate of arrival time to work out which train to aim for. I can’t “just remove 10 mins on the time if I know that a router has given me an inaccurate route” because the inaccurate route isn’t necessarily on the bit of road immediately in front of me; it might be miles away.
That sounds interesting - some more detail would be useful. Also, PRs welcome!
The edge case I was talking about only applied when routing to literally cross a road. If you’re routing to a train station I cannot see any reason that you’d have an inaccurate route and route timings assuming crossings have been mapped correctly wherever there is a junction or a path joins the pavement.
Will absolutely share stuff! Currently the thing I’ve built is just a terrible python script to test if it was possible. My plan is to build a router from scratch but I might go submit a PR to try and add it on another router seeing as that’s probably faster.
At a T-junction there’s often a dropped kerb (implying an unmarked crossing) between the two sides of the terminating road, but often not across the continuing road - so it would not be “correct” to map a crossing there. People do it because otherwise routing doesn’t work, sure, but it’s a hack (you could possibly make the argument that it’s an informal crossing).
It also makes separated pavements useless again for routing wheelchair users because routers aren’t taking into account tags such as lowered kerbs (that I know of). To keep pedestrian routing accessible for wheelchairs you’d need to only map crossings with lowered kerbs.
That’s a router problem, one I’m working on fixing hopefully. Would be nice to have a way to mark a crossing as “informal” or specifically for the purposes of routing in the meantime.
Out of interest would a router that could hop between pavements for those who want to be able to do that solve most of the issues with separate pavements for you? If it ends up becoming a non-issue for routing in the future would you still have any objections to separately mapping all pavements?
Technically crossing=informaldoes exist, but I don’t think it’s really designed for this.
My only strong opinion is that it works with that in mind:
“Hopping” is probably out of the question, as was discussed in part towards the beginning of this thread. It just doesn’t seem feasible to me, and I think most router developers agree.
Conversely, making the router aware of which side of the road it’s on seems feasible (and then it’s simply a case of toggling rules for the router on where it can/cannot cross).
In fact I think I’ve done a kata that’s sort-of like this..
..but I also feel like this must be something someone has tried before.
Similarly, it seems relatively feasible to just have a point-and-click way of “building up” the road once it’s mapped, so building up the data on integrated pavements would be a much simpler case of moving up and down the road.
This would allow a lot of data (lowered kerbs, studs, but also parking, bike lanes, etc) to be created and maintained without having to worry about placing the data in 2D space.
I could see myself building this, but currently it’s a bit pointless.
Mapping 1-3x the number of ways creates 1-3x the amount of work and 1-3x the amount of potential errors - both in creating and maintaining the data. So I do think “less is more” when it comes to this sort of thing.
Additionally, it’s much harder to break routing with integrated/tagged pavements because the router can just degrade neatly to pretending you’re a car.
And also because it’s so much easier for me to fix bad tags than it is for me to fix bad ways.
This is basically my reasoning for thinking that integrated pavements is the best way forward, for most roads in the UK. But yeh, the goal is a working map - and in fact if the separated pavements were working even sort-of fine then I would have just used them.
Not sure this is a big consolation for sidewalk users in Ealing, or elsewhere in the UK for that matter?
Is there source and running instructions available so communities elsewhere can use it? I would actually genuinely be interested in running it for southern Ontario.
Correct - however, the scope of this thread has clearly expanded to general discussion of separately-mapped sidewalks, and my point is that “routers aren’t taking kerb=* tags into account” is:
not entirely true, as this is working in-production for an existing router (though obviously, ours is niche and does not have global coverage); and,
even if no routers did use these kerb=* tags, this is again shifting the responsibility from where it truly lies with routers onto OSM. Mapping separate sidewalks and curbs is valid data and does belong in OSM, whether or not existing software makes use of that data.
Unfortunately, no - and sorry, that’s out of my hands. The currently-deployed version is not public, though there are some older repos here and here.
I appreciate the link to AccessMap and I hope this could be upstreamed and/or made available outside of specific cities (although I acknowledge what you say about it being out of your hands).
Almost - we’re talking about it in the context of UK roads, not generally. Manchester is not really very much like Seattle (although it is sort-of like New York in places).
I guess many of us are explicitly challenging this - it’s not valid data if it doesn’t represent reality on the ground. The entirety of the road is a pedestrian way in the UK (legally in most places, practically in many), not just the carriageway, so mapping separate ways in the UK sort-of looks a lot more like a hack for routing purposes.
(Note: I’m fine with hacks that work, the world runs on hacks that work. This hack isn’t working!)
Note that this is also true of cycle lanes - cyclists sometimes get their own “mandatory cycle lane”, which means that cars aren’t allowed to drive in them (although frustratingly, they are sometimes allowed to park in them). But cyclists are still allowed to use the rest of the carriageway (and often need to, e.g. to turn right, or to go around said parked cars).
These cycle lanes are integrated into the road, so mapping them separately seems like a hack (and you’d need to draw lots of connections between the cycle lane and the road to compensate).
Yeah, this is a tricky on the both mapping styles have their pros and cons. Personally, I think if the sidewalk has a clear physical separation or important details to capture, mapping it separately makes sense. But for simple kerb-separated paths, keeping it as sidewalk=left/right/both feels cleaner and avoids unnecessary complexity.
You do not even have to know the location, this can be achieved fully from aerials.
and partly because as I’ve worked on this I have become more convinced that mapping separate ways on most UK roads makes the map less accurate (although definitely more detailed).
