Mapping paths in a park

General talk
, , , ,
1

Hi everyone. I’m planning a simple thing: walking to the nearby park and mapping/updating all the paths I find. The problem is, I’m unsure on tagging. Looks like every single walkable path should be mapped as highway=path with no regard to hierarchy.

This feels weird to be, because for car navigation and rendering we have an extensive tagging schema which includes not only physical properties, but also hierarchy: trunk, primary, secondary etc. It’s known to anyone who’s ever been in a park that paths can also be sorted into those that are used for “transit traffic” and smaller ones.

4paths
4paths1600×600 491 KB

While many people say we should not map anything outside the physical properties, I wonder how our routing engines choose which path to take. E.g. we have a long standing issue with bicycle routing on paths, because the only option of marking a path unridable is setting an access restriction (bicycle=no) which is obviously incorrect.

Generally I just want to tell “transit”, well-walked paths from narrow regular paths in my park. Is there a way to do that?

See also: Documenting the problems with `highway=path` , Documenting solution proposals for `highway=path` , and Request for Comments: Solution proposal for the `path` issues .

7 Likes
2

This is not true.
There is: sac_scale, mtb:scale, smoothness, surface, and trail_visibility that routers can use to determine if a path is suitable for road cycling, mountain biking, or anything in between.

Generally I just want to tell “transit”, well-walked paths from narrow regular paths in my park. Is there a way to do that?

In a addition to the ones mentioned above there is also width and informal.

11 Likes
3

Even without an exact routing engine in mind, there are many objectives such as surface, smoothness and width, as well as all the keys that @maasa123 already mentioned.
In my opinion it makes a big difference from

  1. surface=asphalt, smoothness=excellent, segregated=yes, cycleway:width=2+.5 to
  2. surface=woodchips, smoothness=bad, width=2 to
  3. surface=ground, smoothness=bad, width=1.5 to
  4. surface=earth, smoothness=bad, informal=yes, width=0.2

(All values are made up, so please don’t copy and paste them to OSM! :grin:)

See also: VeloMap.org -Roadbike - Bicycle - Maps based on Openstreetmap « Participate in OSM – Tagging Guidelines
And: https://support.komoot.com/hc/en-us/articles/10194668255258-Improve-the-komoot-Map

7 Likes
4

As far as I’m aware there is currently no concensus. Roads have gazillion different categories plus all the tags for surface and whatever, while us suckers walking on paths have only one category and we have to do mental gymnastic of figuring out what 20 fields actually mean in practice. Not to mention that more-or-less nobody making maps cares about those tags or the legend is so convoluted to figure out which micrometer between the dots or lines is which tag. Sad but true.
In addition to your photos of the park paths, I have many more that can hardly be called paths in any sense, except that they lead to a certain destination, yet they are and will continue to be mapped as paths. On weekends I’ll be visiting some more routes that are unmarked paths but lead over ridges. Due to strong opinions in the community, I now only add a cairn mark or whatever I find along the way, if at all.

7 Likes
5

I have submitted a talk proposal to SOTM 2026 on a related (and consensual) topic, hoping that it will provide a reason for organizing a BoF session and discuss these things among those who really face these issues every day. Meet you in Paris!

2 Likes
6

Oh. And if a few of you are interested, we might be able to organize an outdoors mapping session in or around Paris, just before or just after SOTM. And focus on paths, trails, tracks, non-paths, all the real stuff.

7

Before you start pointing to the physical properties of paths you see on the photos (oh, you’ve started already, oh well), consider why we have car highway classification, instead of mapping their physical properties (width, surface, lane count etc).

And how come routers depend on those primarily, while using physical properties to adjust weights after that?

Regarding the tags mentioned:

  • SAC scale is a scale by Swiss Alpine Club, of which only strolling and hiking make sense in parks, and even then, it’s hard to argue tagging park paths to be graded on a SAC scale. It tells us literally nothing, especially how often a path is used.
  • It’s really uncommon finding a path with mtb:scale different from zero in a city in Eastern Europe. So this tag is equally unapplicable.
  • Same for trail_visibility: I’m talking about definitive excellent values here. It’s not a matter of knowing where to go.
  • Smoothness and surface can be the same for the left pair of photos and for the right pair, but their use is different. A well-maintained park can only have paved paths, so how do we separate them otherwise? A forest park, which I intend to map, has only walked-in unpaved paths, which would be mapped the same.
  • Width would not help because even walked-in, high usage paths can have narrow spots.
  • informal=yes is a really weird tag, especially when dealing with a forest park. Does a bench placed alongside a path make the entire path formal? Being included to an official map? Is a path that’s used by 20 people/hour formal or not?

What I’m saying is, for highway=trunk, physical properties come as a result of its class. Many cars are using it, so the government might make it wider and construct better amenities because it’s trunk. Routers tend to use the highway classification because other people are choosing their routes according to this classification, whether they are using maps or just choosing the fastest route.

So what I want is to follow where other people go, not the surface or the Swiss Alpine Club guidance for my local park.

3 Likes
8

I think I understand the problem you are trying to solve, but I still don’t think “where people go” is a stable or verifiable path classification in the same way as road classification.

For roads, highway=trunk/primary/secondary/... is not just a popularity metric. It usually reflects a legal/administrative/network role. Physical properties often correlate with that, but the classification is not simply “many people use this road”.

For park paths, especially informal forest-park paths, we usually do not have that same hierarchy. A path used by 20 people/hour may still be informal if it was not planned, built, signed, maintained, or officially designated. A quiet paved path may be formal even if it has low usage. Usage is also highly variable by time of day, season, weather, nearby events, and mapper perception.

That is why I think the existing physical/access tags are still the least bad option:

surface=*, smoothness=*, width=*, trail_visibility=*, informal=yes, sac_scale=* where appropriate, and mtb:scale=* where appropriate.

I agree that this is not perfect, and I agree that path rendering/routing is often poor. But adding a new “transit/well-used” class risks becoming subjective unless it has a very clear definition. Otherwise two mappers may tag the same path differently based on when they visited it.

For the examples you describe, I would probably separate things roughly like this:

A paved or maintained park path:
highway=path
surface=asphalt/paved/compacted
possibly lit=*, width=*, smoothness=*

A clear unpaved park path:
highway=path
surface=ground/earth/compacted
width=*
smoothness=*
trail_visibility=excellent/good

A desire path:
highway=path
informal=yes
surface=ground/earth
width=*
possibly trail_visibility=*

That does not solve every routing issue, but it gives routers and renderers actual observable properties to work with. The missing part is probably better consumer support for these tags, not replacing them with a popularity-based classification that is difficult to verify.

2 Likes
9

Except that, seen from a highway=* perspective, this is all the same.

SARCASM ON (not towards you, Ilya, rather towards the situation)
Maybe you should tag all the ways in the park as cycleways with foot=yes
SARCASM OFF

10

And, of course, that is never happening with roads.

Please, just have a quick look across maps in Bosnia and you’ll see trunk roads leading to the front doors of houses in the hills, while being nothing more than two lighter lines across a grass field.

I won’t go into tag comparisons since that topic has been beaten to death multiple times already.

1 Like
11

My understanding is that tracktype serves a similar classification purpose for tracks. Or at least it did. But looking at the 100s of posts in currently active threads on this topic, it seems there has been a process where the physical characteristics typical of each grade are now seeing by many as defining the grade. Many mappers now push back strongly against any definition that can’t be reduced strictly to a list of physical properties. I fear that any attempt to classify paths would meet the same fate, and end up as just one more physical tag in the long list required for even basic path mapping.

1 Like
12

Agreed. I think the main problem with classifying tracks and paths is that there are no widespread well known classifications in reality for those, as there are for roads.

Traffic infrastructure is heavily motor-vehicle centered and there are lots of road classfications quite well known to the average person. In Germany we have Autobahn, Kfz-Straße, Bundesstraße, Landstraße, and lots more - and all these terms have some meaning for most people without making detailed explanation and lots of sample pics necessary. That makes it very easy to establish a similar set of values for mapping use.

There is nothing comparable for tracks or paths. A track is nothing but a very low grade road classification and a path is a path. We don’t have separate terms for a wide and comfortable paved path, a well maintained and smooth unpaved path or a narrow path with a rough surface. The only way to distinguish these in real life is specifying the width, the surface and the smoothness, in real life and consequently as well in mapping.

The only exception in german language is the Trampelpfad meaning an informal path which has it’s own value in OSM as well.

If we would start to create our own definitions for different kinds of paths as shown in the sample pics we would most probably end up with the same problem we are facing with tracktype - a set of values which are not understood and accepted by every mapper leading to endless debates again and again.

I don’t say we should not try. I personally think tracktype is a very helpful tag and I use it as basic classification for each and every track I map before adding surface and smoothness. We could have something similary for paths but we would have to accept the same problems we already experienced with tracktype.

8 Likes
13

At least in English we do: trail, rail trail, path, MUP, walkway, promenade…

14

I would not map the first one as a path, but as a paved two-way cycleway with a sidewalk. I think mapping this as a highway=path is only done in Germany. That said, there sure are paved paths with legal access for both walking and cycling.

2, 3 and 4: All excellent paths for hiking/walking. Map surface, maybe also smoothness and width.

I’ve seen mappers apply tracktype as well, not a bad idea I think. Tracktype gives surface/firmness with an eye on function and usability.

6 Likes
15

Thank you for taking the time to investigate the issue (and adding links to the previous discussions), as well as trying to narrow it down by emphasizing “parkways.”

First, I too think that your fundamental assumption that the classification of trunk, primary, etc. would neatly transfer to the wold of multi-use non-motorized ways doesn’t really hold true. For reasons that have been discussed earlier, and which @maasa123 exquisitely crystallized:

Secondly, a partial solution has been implemented in parts of the OSM-world (including mine) in that the very first “path” would not be tagged with highway=path here, but rather highway=cycleway. Of course this isn’t a perfect solution, as people elsewhere have mental problems tagging a multi-use path accessible also to pedestrians as cycleway (or footway for that matter for “paths” accessible also to bicycles). At the very least, that path could have a bicycle=designated tag (as well as foot=designated of course).

I also think that dismissing the tagging of verifiable physical properties isn’t really helpful either. Those tags are the primary ones I filter when planning my bicycle tours.

But yeah, although the issue at hand seems nonresolvable, I still think discussing it every blue moon is a good thing. Perhaps we’ll be able to eke out a better solution one day!

16

I agree. It would be good to have a functional classification scheme for paths (including footway, cycleway, bridleway) mirroring the highway=trunk/primary/secondary/tertiary/unclassified classification for general purpose roads. Unfortunately the “verifiable physical properties only” crowd will push back vehemently against such a thing.

Yes, it does, and although it is mainly used on highway=track, it is also found combined with other highway=* values. Further promoting the use of tracktype classification on highway=path/footway/cycleway/bridleway could be a path forward, but yes it would be a struggle against those who consider strict verifiability to be of the utmost importance.

It is weird, but it is the only tag I’m aware of that some data consumers are actually using to de-emphasize certain paths while emphasizing others. Formal vs informal isn’t exactly an importance based classification, but it is often highly correlated with formal paths being more important than informal. So data consumers can interpret it like a two level classification for certain purposes. In the context of a park, an informal path is one that the park managers didn’t create and/or don’t condone the use of. Yes it can be tricky to decide in certain situations, just as deciding between highway=tertiary and highway=unclassified can be.

2 Likes
17

I suppose I belong to that crowd. So here’s my 2¢.

The reason I find such classification (again, with the intent of mirroring trunk, primary, etc. for multi-use paths) difficult is that I can’t think of a way to do such classification that wouldn’t simply coalesce with the different physical properties a multi-use non-motorized way would have. And I’m here understanding traffic signs as physical properties. Why not, then, just tag the physical properties and traffic signs instead?

Unless one starts to consider stuff like “where people go” (as @maasa123) said above, or ‘connectedness’, or ‘importance’ in the topology or network of pathways. Here we’d soon veer off to subjective assessments. Multi-use pathways don’t usually form dense enough networks, particularly long-distance, that would warrant a complex gradation scheme outside of their physical properties.

4 Likes
18

And the reason I find it difficult is that I expect any coalescence to only apply in the area around the person designing it, much like how tracktype really only works well for agricultural tracks in northern Europe.

1 Like
19

Surely we have “car highway classification” because it exists in the real world outside OSM? Where I am in the UK we have public roads that are motorway, trunk, primary, secondary and unclassified; various oddities that tend to get mapped as track, and private or permissive service roads. Of the OSM “car roads”, only tertiary and residential are actual OSM inventions.

We don’t have, and I can’t think of anywhere that does have, a similar “pedestrian highway classification” (although some places do have something a bit like that for bicycles - at least in name).

Surely not - the router or map that you’re looking at does that for you.

So make your own map? An example schema (that I use for both raster and vector maps) is here. It separates paths into several categories. Ignoring the ones based on designation (likely not relevant to you if you’re outside England and Wales), you can see a split between pathwide and pathnarrow, and between good, not-good, “intermediate trail_visibility” and “bad trail_visibility” (actually a selection of tags is used to determine what bucket things go in). If you want to change the colour of “good narrow paths” from black to puce you just need to edit this line in the vector style to change it it vector maps. If the schema already has the data in it you don’t need to make new vector tiles, just edit one text file.

Outside of the UK, there are many endless discussions about “is this road a trunk or not” - often it’s OSM class comes out of its physical properties! There are also plenty of places (perhaps you remember this one) where the official classification is so far adrift of the road quality that the OSM class has been all over the place.

Is there an implied quality to any of those in your dialect of English? There mostly isn’t in mine; the exception maybe is “mutli-user path” which implies that it’s usable by at least some people on wheels (so likely a lower tracktype, a better smoothness and a better surface). A “rail trail” is likely fairly flat, but other than that you’d struggle to assume anything. The others just mean “some sort of path” in English English.

1 Like
20

I’m sure that other people can think of examples, but I bet that someone somewhere is using pretty much everything that can occur with a highway tag for use for further classification. My example code for that starts around here and uses a dozen or so tags. Just the differences between paved, unpaved, and informal can be seen on this map.

1 Like