Footpaths through open areas: redundant?

Evening again,

Our city market is a good shortcut (as well as being a moderately interesting walk).

Are footpaths through the market like this one useful?

Or - given that you can wander anywhere you like, and the ‘footpath’ is more a desire-line than a there-on-the-ground path - would the whole area be better tagged as a pedestrian area?

Yours noobily,


Do the footpaths exist on the ground?

My view is that one should not map arbitrary paths, which are not delimited on the ground, and it violates the tagging for the renderer rule, but I’ve found that when I correct this, someone, probably not the original mapper will add them back.

One of the reasons for this is that routers don’t seem to understand areas. I’ve seen one treat the area as though it were a path around the area. However routers are renderers for the tagging for the renderer rule, so one should not be adding virtual paths to work round the broken routers.

I would not say that a router is broken when it handles areas like that. If your area contains obstacles like trees, fountans etc it is not that easy to calculate and show a “good” path. The router has to know and evaluate many tags to find out if an object inside the area is an obstacle or not and it has to guess the size in case the object is mapped as a node. For example, a node with tourism=information might be something you want to get closer, a node with amenity=waste_basket is something you may want to avoid.
Some mappers use funny values like highway=virtual or highway=none to map often used ways through areas.

In the case I’m thinking of, there was a long peninsular to the pedestrian area, so people were routed a long way up one side of side path, and then back down the other side of it. They way to handle obstacles is to map them.

Also more than once I have seen routes that go straight through statues or war memorials, and at least one of those was virtual.

This is a typical example of how people end up mapping virtual footpaths to tag for routers.

I at least noted this in the past, and I thought it had been corrected, but either it didn’t get corrected or it suffered a regression.

If you look a the aerial imagery, you can see you need mountaineering equipment (as well as a sharp lookout for police) to follow the path, and even if the statue wasn’t there, no normal user of the island would follow the routes shown; they would take more or less the shortest route to the exit they wanted.

This problem needs addressing in routers, or people will continue to add these fictional, and often impossible, footpaths. Although it breaks the tagging for the renderer principle, hinted routes would be better than completely fictional ones. Even then we are going to see them going straight though obstacles, because the same desire to connect the routing graph will take precedence over proper surveying.

And what about route relations, e.g. walking routes that pass through pedestrian zones. Often a virtual path is added, so it can be placed into the route relation.

Data consumers understand roundabouts in route relations, as a special case, why should they not understand area=yes on highway=pedestrian?

If you really are going to have virtual paths, they need to be clearly distinguished from physical paths (and need to be surveyed to determine real life usage). They probably need to be rendered on the standard layer, otherwise people will think they are missing and add them as physical paths.

Note there is a preprocessing solution that works quite well on smaller extracts (takes roughly an hour on Switzerland):

Also now being debated on the map note I just added to report the Trafalgar Square route for mountaineers:

Roundabouts are still ways.

For areas, it would mean that you have to start splitting them for the purpose of the route relation, just like we do for streets represented by ways. We only add the part that has to be followed for the route, not the whole street.

Because finding the optimum route around a linear roundabout requires no special handling, whereas finding the optimum route across a polygon is non-trivial to compute and no-one has yet stepped up to the plate to implement it in the major routers.

If you feel very strongly about this, I would suggest that your energy might be more productively directed towards submitting patches for OSRM, Graphhopper, Osmand and the like, rather than raging about it in forums/changeset comments.

It has always been the responsibility of data consumers to use the data correctly, not for data producers to pander for their weaknesses; that’s why the don’t tag for the renderer rule exists. Trying to avoid this by saying a data producer must do the development work for the consumer (and without even knowing whether they have the skill to do that), is, in my view inappropriate.

In any case, in many of the cases, the polygon is convex and has no cutouts, in which case the routing only becomes difficult if two polygons share edges.

As I’ve demonstrated, some of the fictitious paths that people add are actually worse than the result of simply using the shortest path over a convex polygon, as the fictitious paths have been added by an algorithm that doesn’t take account of everything mapped and certainly doesn’t take account of the real world, but also doesn’t produce the route that a real person would use, when there are no obstructions.

The reason that I added a note, and didn’t just remove the fictitious paths is that I’d likely end up in an edit war, and I can do without the stress and time wasting of that. Edit wars are an, unfortunate, side effect of an environment with only weak central control. The reason I don’t re-arrange the paths into ones that are physically possible to use, is that that would be acknowledging that tagging for the renderer was appropriate.

Although the best solution is for routers to use the real world information to choose a best route, if one has to compromise, fictitious paths should not be highway=footway, but should be something that clearly indicates they are not real. Although you could argue that it would be up to the renderer, if you used something like routing_hint=yes, there has to be some sort of principle that common cases should be recognizable based on just a few tags, so a renderer seeing highway=footway should not have to look further to realise it doensn’t really exist. As such, I’d say highway=routing_hint, is better than an additional flag, if they must be included.

Of course any such hint is unverifiable, as it represents a personal judgement.

I also note that one contributor to this thread has pointed to a tool that already allows such hints to be be generated for routers. I haven’t looked closely at it, so I don’t know how it works, but, in principle, it could presumably create a database that could be substituted for planet.osm, and allow routers to work without modification.

Nope. It has always, in the 14 years I’ve been involved in OSM, been the responsibility of data consumers and mappers to find a pragmatic happy medium. OSM works by consensus. We are not Wikipedia where everything is enforced by Rules.

I confess to not anticipating how much controversy there is on OSM!

This may not be the place, but what about a tag *=desire_line for this type of route?

That seems to be a pretty exact term for what we’re talking about, and is in frequent use among transport planners. See

  • especially the bit half way through, about snow paths and Michigan State University.

Any thoughts? Any suitable forum to put this forward?

Going back to the original question, I guess that there are a bunch of food stalls in there, and personally I’d probably map this path at the same time that I mapped those. If you think it needs adding now though, I’d definitely join it to the footpath through Laxton Square. I’d also definitely map the gates into the area.

You’re (I presume) local to Peterborough, and I presume that the other people in this forum thread aren’t. There aren’t that many active mappers in Peterborough (the history there suggests only a couple in the last few days). I wouldn’t worry too much about trying to create a “proposal” for a new highway type; you can add far more to OSM by just mapping stuff than trying to change the way that things tend to be tagged.

Thanks for all the replies. Following SomeoneElse I’ve deleted the footpath for now - I’ll reinstate it once I’ve mapped the internal layout of the market.