Hi, following on from a conversation in the OSM World Discord, I would like to reach the wider OSM community audience before editing the guidelines on the related wiki pages.
This aims to clean up some of the ambiguity around the way footway areas are described, as both wiki pages conflict in some areas or provide unclear instructions to the difference between area:highway=footway and highway=footway + area=yes. I propose adding a section on both the Tag:area:highway=footway - OpenStreetMap Wiki and Tag:highway=footway - OpenStreetMap Wiki pages describing the difference as follows. I have already talked to some community members and came up with these definitions, but would like to reach a wider audience to see if thereâs any alterations needed before changing wiki pages.
area:highway=footway should be used for smaller linear areas such as sidewalks. An area is âlinearâ if the majority of people walking through it would follow the same path as a singular way with highway=footway running through the area. area:highway=footway should ideally always have a highway=footway way inside of it, going from one end to the other.
highway=footway + area=yes is for open, free flowing areas. These are where people walking through the area are likely to take different paths, and have different destinations from each other. These are areas that could not be represented easily by a single or couple of ways due to the variance in destinations and paths. These will not necessarily always have a highway=footway area running through them, unless to connect various destinations on either side of the footway area.
For any footway area that is large enough for a motor vehicle to comfortably drive around a pedestrian area should be considered instead, depending on local preferences.
Please comment any feedback around these proposed changes or any way the descriptions could be improved to be more accessible to a wider audience, especially those less familiar with English. I plan on adding images of the relevant areas too.
Currently all area:highway objects are literally just there for splashing some additional colour around and donât really have any other functional use in practice.
highway=* polygons with area=yes (to distinguish them from linear features, for example roundabouts) will (besides colour again) be used by some routers to route along the edges if no appropriate linear feature is available.
This will change with more routers supporting navigating over areas (coming to OSRM rsn for example), the thing is, if you are not just splashing colour, you will probably want to map areas as contiguous as possible/reasonable to allow visibility algorithms to do their magic. This is likely not what current users of area:highway are doing.
Which tagging scheme to use (area:highway vs highway) for this is completely out in the open right now and I would consider it very premature to try and bake that in to a recommendation. Particularly a recommendation that is based on criteria that seem to be largely irrelevant.
I think that the text in the original post outlines the intended distinction between the two tags quite well.
(While I do think the text can be used as-is, I would personally go beyond saying that highway=footway + area=yes polygons âwill not necessarily alwaysâ have highway=footway ways running through them. They should usually not have highway=footway ways running through them. Drawing those ways is mapping for the router due to the current lack of support for navigating over areas. Which is perfectly understandable, but we shouldnât forget that itâs a temporary hack.)
It would of course be good to refine the definitions of when and how to use these tags once we have input from data consumers using them for real-world use cases. But people who are currently mapping areas need to base their choice of tags on something. And the proposed clarification is both aligned with the original intent of the tags and also seems like it shouldnât impede future use cases in either routing or rendering.
This is not what area:highway=* is about right? area:highway=* should be used to represent the area of a highway for visual representation (and maybe for routers to calculate the width).
area:highway=* describes the shape (i.e. the two-dimensional outline of the area) of a highway, or parts of it. It is used as a form of micromapping in addition to the routable, linear way tagged as highway=* .
Differentiation area:highway vs. area=yes on a highway
area:highway=* had been proposed to describe the non-routable, detailed shape of a (typically linear) highway. The tag requires the linear, routable direction of the highway mapped in addition as lines with highway=*.
area=yes on a highway=* describes a routable highway area on which the dedicated traffic can route omnidirectionally; i.e. from any point along the edge to any other. This is typical for pedestrian areas, or service areas where vehicles drive without prescribed lanes. The rationale is that routing engines should consider those omnidirectional objects in addition to nodes and edges in classical graph theory; thus no linear highway lines would be required within. However, as of 2019, OpenTripPlanner is the only OSM-based router that supports routing over areas. It does so by computing a visibility graph over the area. [1]
This should be highway=pedestrian + area=yes right? `. Because otherwise I donât understand the difference with:
on the area=yes wiki is written:
Note: There is currently no clear agreement on how highway tag values other than pedestrian should be treated when also tagged with area=yes.
In my conclusion:
highway=footway is used to create routable paths for pedestrians that normally donât have any name (other than from the adjacent street). For instance: a sidewalk, a path through a forest (for pedestrians/hikers), the few paving stones to get from a parking lot to the street, etc.
area:highway=footway is used to let a renderer or router know the above created footway is 2m wide or shaped like a triangle (as example).
highway=footway + area=yes is nothing
highway=pedestrian is used to create routable streets for pedestrians. When there is no other street next to it. (For instance)
area:highway=pedestrian is used to let a renderer or router know the above created pedestrian street/way is 6m wide and fills the complete space between two rows of buildings (except that cute flowerbed that will be cut out)
highway=pedestrian + area=yes is used to mark a free-flowing area. For pedestrians itâs possible to navigate from every point on every edge to every point on every edge.
Ideally a router doesnât need the separate highway together with the area:higway, but we will break navigation if we change them now from a way to an area.
area:highway=* â for features where traffic has a clear direction where the semantics and routing graph are best represented by a highway=* way. Always used in combination with the corresponding way.
highway=* + area=yes â for areas where traffic can go in any direction in the general area (e.g. pedestrian squares or large service areas for vehicles)
highway=* + area=yes also implies area:highway=*
That applies to all highway=* types, thereâs no limit to the types where it can be applied or special cases with different meanings. Of course, for a lot of highway types the second case just doesnât ever happen. You wonât ever see a (correct) highway=motorway + area=yes for example.
area:highway=* is mostly just used by renderers at the moment, but thereâs no inherent reason why it canât be used for other purposes. Itâs just not really used for routing because only using the associated linear highway=* abstractions is much, much easier and there isnât a lot of additional benefit to using the areas as well.
Of course it is. Itâs a footway area with the characteristics mentioned above. Not every area that is primarily meant to be used on foot is suddenly a highway=pedestrian simply because itâs an area.
The larger paved areas in this park are highway=footway + area=yes for example. (The paths are linear highway=footway ways + area:highway)
I wonder how many routers would need to implement this functionality before we declare a critical mass and start deleting the virtual footways, or whether weâd start deleting them sooner as a forcing function.
Hopefully the OSRM implementation will come with reasonable performance. Until now, the most widely deployed router that routed through areas has probably been OpenTripPlanner, but the functionality is off by default for performance reasons, and Iâve heard that few deployments enable it. (Per Pedes Routing apparently also has similar functionality.) Beyond server-side routers, the routers built into mobile navigation applications like OsmAnd and Organic Maps/CoMaps have fewer computing resources to perform intensive postprocessing, but these are exactly the routers that pedestrians would need accurate turn-by-turn directions from the most.
The pull request discussion has already veered into implementing âhoppingâ between disconnected paths, calling into question tags like footway=link. Iâve seen Transit hop from the public transportation network to the pedestrian network out of necessity, but hopping more generally would probably turn up a lot of interesting edge cases.
Yes, there is clearly a meaning to âwhere the paved surface begins and endsâ beyond splashing color on the map. Aside from rendering and routing in a narrow sense, area:highway=* could be useful for geofencing with enough coverage. Based on these areas, navigation applications could relax off-route detection at fan-outs, ferry waiting areas, and other widened spots that are difficult to express with width=* or lanes=* alone. Location-based games could potentially tie some functionality to whether the user is on the path or not, with slightly more precision than heuristics based on tags.
This is all kind of in the weeds, edge cases rather than critical functionality, but micromapping can also open the door to innovative use cases beyond the ones weâre currently serving. For example, an application could potentially help vision-impaired users learn to shoreline around their neighborhoodâs sidewalks. Due to potential uses like this, my local community would be pretty interested in reimporting all the sidewalks as areas from our original source, complementing the highway=footway ways that we had to derive programmatically.
Topology would be important for any highway=pedestrian or highway=footway area that we expect to be routable and not just a bout of micromapping. A validator like the one in iD would already ensure that the area is at least minimally connected to the routing network. However, I donât think we have anything checking for gaps in adjacent highway areas.[1] Weâll need this check if we start moving away from manually mapped footways through these areas, since even an imperceptibly small gap would create a large detour in the visibility graph.
As for area:highway=*, weâre already kind of inconsistent about whether micromapped areas should connect to the overall routable network. On the one hand, a man_made=bridge area is supposed to connect to the roadway passing over, but on the other hand, many mappers wouldnât bother to connect a service road to an amenity=parking area and would even frown upon that practice. Fortunately, geofencing use cases should be largely unaffected by topology issues. Iâd liken it to natural=waterwater=river areas, which we connect to each other so itâs intuitive and tidy, but not for machine readability.
I did miss it, thanks! This is an important development. Question is, can mobile apps apply this, given the limited computing power available. If this is doable within reason, and if more pc-applications offer this functionality out of the box, then I would not hesitate and change (simplify) mapping and tagging accordingly. Then it would be up to the data users to do it properly, and we could do away with mapping for the router.
I am afraid that much water will pass under the bridge before weâre at that point, but weâll get there.
OSRM uses contraction hierarchies (you know this naturally) and pre-computes them, so the expensive part, at least what I understand from the PR (I might be wrong though) is going to be then, not while actually computing the route. While the additional edges will definitely not make things faster, it probably isnât going to be such a big impact.
With other words I wouldnât expect it to have any different impact than adding the edges to the OSM input file with plazaroute which has been discussed a number of times GitHub - PlazaRoute/plazaroute: Routing through pedestrian areas (which was slow, but that was never optimized in any dimension).
Depends on how the routing works on the device, you will probably always want to add additional edges when you prepare the routing data file not on device, so likely the above applies too.
For the purposes of this, in general highway=footway is for smaller areas, and highway pedestrian is for larger areas.
This isnât intended to change the usage of any of the tags nor be the definitive definition and I expect it to change later once data consumers give their feedback. Iâm sure thereâs existing mapping that contradicts these definitions and thatâs fine and shouldnât be changed based off these suggestions, thatâs for another time when we have more information and are willing to potentially depreciate a tag or add new ones. This is simply meant to provide some guideline to mappers currently mapping areas which tags they should use as thereâs no cohesive easy to understand definition between wiki pages.
Note, I chose to call them âpedestrian areaâ instead of highway=pedestrian +area=yes or area:highway=pedestrian as thatâs even harder to make a distinction and isnât relevant in most forms of mapping.
Uhm⊠programming and routing are not my native languages, please forgive me if I am a bit slow⊠is the following âtranslationâ correct?
For example, OsmAnd transforms the OSM data into a minidatabase for, among other things, routing on the mobile device. This transformation allows processing the data, and that is where the lines-of-sight for an area can be calculated. Then the calculated lines are added to the minidatabase as invisible routable ways over the area, which makes them available to the routing engine in OsmAnd. This would not require substantial extra processing on the mobie device.
If that is correct, then the calculated ways (âedgesâ) can replace the mapped virtual footways over pedestrian areas.
Probably there are lots of cases where this is not so easy, but most cases I encounter are not that complex. And the âvirtual waysâ system still works.
We mappers would need a simple instruction what to do to activate this process. E.g. connect the approach/exit ways to the pedestrian area with a common node. If cycling is allowed, add bicycle=yes to the pedestrian area outline.
As a hiker, I would also like to know if this can be applied to e.g. a natural area, e.g. natural=heath|sand|grassland with several access ways, where you can walk anywhere.
frankly I do not believe we should make a distinction based on size. The exact size is already implicit when we draw the geometry. What could be used for distinction is whether there are exceptions regarding access:
pedestrian means exceptions are expected (e.g. delivery, loading, taxi, police, sometimes bicycles, residents, at certain times, etc.), while a footway is typically limited to pedestrians (and sometimes bicycles, with additional tagging, or emergency vehicles, which are not bound to general access restrictions anyway when responding to an emergency).
Iâve dreamt of something like this too, but I could imagine it being quite difficult to support well.
Unless the visibility graph accounts for things like walls or long benches cutting across a pedestrian plaza (as PlazaRoute might), the result would be something of an approximation. Routing over open space would increase the need to account for barriers that arenât as easy to connect to the routing graph, such as waterways, as well as elevation changes that might have to come from an elevation model rather than OSM.
The documented notion of default access restrictions on highway=* ways already suffers from poor software support, let alone default access restrictions on landcover areas. Are we going to start blanketing these areas with explicit access tags, just in case, like we often do on roadways?
One of the assumptions of these routing graph enhancements is that the entrances and exits are modeled explicitly as connections between pathways and pedestrian areas. But mappers really donât like to connect landuse areas to roadways and pathways, let alone landcover areas.
Defining highway=pedestrian based on these exceptions is really unintuitive. It would be like defining highway=motorway based on the kind of vehicles banned from it. A more intuitive distinction would be highway=pedestrian areas for pedestrian plazas and highway=pedestrian ways for pedestrian streets (pedestrian malls), but highway=footway areas for any other space built for undirected foot traffic. The term âpedestrian streetâ makes it pretty obvious that the way functions like an ordinary street except for the kind of traffic that normally uses it. That can explain not only the access exceptions but also the name in many cases.
Iâm not sure if this is a mere observation or a criticism.
iD prompts you to connect a carpark to an access aisle, and Iâve no problem with that and similar policies.
The problematic stuff in my view is stuff like this (retail area that was glued on all sides to roads; still is mostly), and this (boundary between jurisdictions used as bounds of landcover - therefore boundary is highly likely to get moved or broken in subsequent edits).
I see this a different kettle of fish: A carpark aisle is definitely reserved for driving and not for parking; Depending on the actual occupation of the parking spaces perhaps there might be more aisles than marked on the ground. While a âvirtualâ pedestrian highway going through a pedestrian area also depends on occupation, it does that much less strictly so. There are no ground markings: Here to pause and chat, here to walk and commute, arenât there?
So a (pedestrian, predominantly) router that uses areas ideally should ignore all those âvirtualâ routes that mappers provided as a guide or a fallback.
iD will warn if a footway goes near a service road without connecting to it, but the amenity=parking area doesnât factor into that. Personally, I do connect service roads to parking lots, but it isnât especially common. Besides, not everyone can squeeze through two parked oversized SUVs in order to make a beeline dash through a large, full parking lot, so a visibility graph would be less useful in that context.
Thatâs just it: in order to extend this area routing implementation to include landcover areas, weâd have to glue landcover areas to roadways. I wasnât critiquing your request so much as juxtaposing it with this suggestion earlier.
.JPG){kind=link}