It seems that routing does not work on pedestrian areas, as I can see it in this place

Routing not working through pedestrian area

So, how should we be tagging so that tracking works in these areas?

asked 28 May '19, 13:12

garaolaza's gravatar image

accept rate: 0%

Open Trip Planner does area routing,

If you look at the guidelines they also list how to do area routing for other routing engines:

As you see here it is quite okay to mark the main linear features of an area, while it won't yield as good an answer as an area router (unless you went mad and added all possible movements!)

For the above example it would be quite okay to add a "F" shaped set of links within the area, while you shouldn't tag for the renderer it seems like the renders know not to render pedetrian ways within an area, that or it's invisible.

permanent link

answered 26 Jun '20, 17:48

DevonshireBoy42's gravatar image

accept rate: 0%

Note: Most pedestrian routing algorithms do not currently route (correctly) across area features, tending to route around the edge or not at all (especially in case of multipolygons). Do not alter your mapping to accommodate such routers.


So I think, we will need to wait routers to be fixed. Have you consider creating issues on routers trackers?

permanent link

answered 28 May '19, 22:16

Binnette's gravatar image

accept rate: 0%

There are issues already. It’s just a hard problem to solve (and one with comparatively little financial reward, so unlikely to be prioritised by paid developers).

(29 May '19, 09:40) Richard ♦

Ideally the various routers should be able to route through an area. But, with what little I know of routing algorithms, this seems to be very hard to do and I am not aware of any router that uses OSM data that does this.

Some mappers figure that a map that actually works for people is preferable to one that doesn't and add "virtual footways" through the pedestrian area aligned with common or logical ways that people usually walk through the area. This allows existing routers to do the right thing. Or at least closer to the right thing than if it is only mapped as an area.

However other mappers are adamant that adding "virtual footways" is tagging for the renderer and should not be done.

Fortunately for me, there are very few pedestrian areas near me so I don't have to get too involved with either school of mapping and can just sit on the side and watch the arguments that haven't changed in the years I've been mapping.

permanent link

answered 28 May '19, 18:48

stf's gravatar image

accept rate: 18%


I feel mapping "virtual footways" is ok as a temporary workaround for routers' shortcomings. However, using the same tag for "virtual footways" as for real footways is not, because doing so negatively affects correctly-written software. This is precisely what the rules against "mapping for the renderer" intend to prevent. (The data would be indistinguishable from the case where there's actually a visibly different path crossing the plaza on the ground.)

It would be utterly trivial for routers which do not support routing across polygons to at least at support ways with some newly made-up tag like routing_hint:highway=footway, allowing the creation of virtual footways that do not interfere with other uses of the data.

(This comment is about actual plazas. There's also a separate problem where mappers incorrectly map pedestrianized streets as highway=pedestrian + area=yes despite being clearly linear.)

(28 May '19, 20:37) Tordanik
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 28 May '19, 13:12

question was seen: 1,031 times

last updated: 26 Jun '20, 17:48

powered by OSQA