National Trust: Car Parks Associated With Trails

Communities United Kingdom
1

Over the last year, the National Trust have sought to capture an inventory of promoted walking trails into OSM as part of an organised editing programme (Organised Editing/Activities/National Trust Paths - OpenStreetMap Wiki), following previous work to capture the path network into OSM in 2022-2023. As part of this, we used relations to collate the geometry and attribution of the trail, and opted to include features that are associated with the trail as part of the relation (eg. recommended car parks). However, we have since found challenges with the way that routing engines represent car parks as part of the walking route; they contribute to the shape lengths and elevation profiles.

See example here: Relation: â€ȘLeith Hill Woodland Bluebell Walk, Leith Hill‬ (â€Ș19894195‬) | OpenStreetMap / Waymarked Trails - Hiking

We have considered a number of options as to how is best to navigate this going forward, but would like feedback from the OSM community on our suggested approach. Note, not all car parks associated with the trails are NT owned and we are cautious not to direct visitors to nearby car parks that are not equipped to deal with those numbers.

Suggested Approach: We propose to retain car parks as part of the relation and use the role (Tag:route=hiking - OpenStreetMap Wiki) to differentiate between the trail itself, and the associated car park.

Currently, role=parking is not an approved or widely used tag, so this would need to go through the formal proposal process. Regardless, we would welcome thoughts from the community on representing this concept in relations, or if there are alternative suggestions.

Thanks in advance.
National Trust GIS Paths & Trails Team.

4 Likes
2

It also applies to other non-walkable areas, like this pub :slight_smile:

3 Likes
3

To be clear, the problem is: you want the parking to be related to the route relation, but if you include it as a member then routing algorithms count the whole area for distance/elevation totals. Walkers could park anywhere in the the area relative to the route paths, so they might not need to walk the length of the car park.

Proposing a new role type seems great to me. Parking is like a “Point of Interest” (POI) that’s important for the walk. I guess the argument would be that apps should be able to calculate nearest parking without it being in the relation, and there’s loads of features they could do that for like toilets etc.

With the example you gave, it looks like it’s trying to be a circular route. I would see no problem mapping a service road or track through the car park. The path can extend into the car park to meet the that road. You can then use this as normal members of the relation, and the car park area doesn’t need to be part of it.

1 Like
5

For what it’s worth there is a documented relation type=provides_features that includes a parking role as and optional element. If I’m reading it correctly you could add the route relation with the target role and then attach the relevant parking amenities to it.

The downside is that I don’t think any consumer orientated software currently supports it, but then they wouldn’t support the new route relation role either.

It does appear to have about 13 thousand uses in the database so if anyone were going to add a “Navigate to Parking” button to their navigation app it might be the scheme they started with?[1]

  1. or they might just search for nearby parking, but if they choose to do that then they’ll probably ignore the parking role on the route relation too. ↩

6

I’m still not convinced it is a good idea to add parking lots to hiking relations because there is no clear definition when a parking lot really belongs to a route or just happens to be used for it because it is nearby. Without a clear definition there is a tendency for these feature to degrade into “might be useful for hikers on the route” and that is something that should be solved by usng geospatial relations.

Why not go about the problem from the point of view of the parking lot? Why not tag the parking lot as designated for the route? Then you can filter nearby parking lots by being for hikers specifically.

6 Likes
7

I think it would be better for a route relation to just contain the member ways of the route, as that keeps things simple and it’s what most tools and data users will expect. Any other associated features would be better represented in some other way. I’d not come across the type=provides_features relation before, but that seems like a good way of doing it.

1 Like
8

Worth noting, of course, that not everyone walking these trails will arrive by car. It would seem strange to tag a car park as part of the trail when walkers might well arrive under their own steam or by bus/train.

Personally I don’t think there’s much need to include them in the relation at all - this is the sort of thing that can be inferred by proximity. You could use the well-established highway=trailhead to denote that the car park is intended for trail users.

6 Likes
9

Looking at the type=provides_feature usage in a bit more detail it seems it has mostly been used to associate addresses with POIs,[1]. This seems an odd use to me, as duplicating addresses onto POIs as properties rather than the primary tag is generally accepted in most regions.

The actual usage for tying physical objects to an amenity are much lower, around 1.6k uses. The vast majority of these are entrances with fewer than 100 recording parking. Despite this I still think it’s probably the best bet for creating an explicit connection without creating confusion for any of the software that already understand route relations.

  1. especially in Belgium and Denmark. Is this because they have a script auto-updating government addresses nodes or something? ↩

10

I agree that the National Trust should prefer to use spatial relationships between amenity=parking and highway=trailhead to represent the preferred parking lots for trails.

11

Thanks for all of the responses so far and feedback on preferred methods of tagging.

Since posting, Relation: â€ȘLeith Hill Woodland Bluebell Walk, Leith Hill‬ (â€Ș19894195‬) | OpenStreetMap has had the role=parking added to the car park, and Waymarked Trails - Hiking now symbolises this differently to the trail geometry. There is also now an option to include / exclude members of the relation that contain a role (eg. parking or approach) from the elevation profile, and downloadable gpx file, and the lengths. This is perhaps more aligned to what we had hoped for when suggesting our initial approach.

That said, we were not previously aware of the type=provides_featuresrelations, so we are grateful that this has been brought to our attention. While this method seems like a sensible option to limit the number of roles that could be created (eg. role=parking, role=pub, role=cafe and so on), all of the documented examples documented for type=provides_features are collating point features.

Following the same logic with trails, we would need to create a new relation featuring all of the amenities and barriers, and add the type=provides_feautres tag to it. We would also need to add role=target / parking to all of the amenities and barriers within the relation.

Would you recommend incorporating the existing relation (the trail itself) too, as this would follow the same logic as in the documented examples? Are there any challenges of creating relations (with type=provides_features) for other relations (the trail itself)?

Alternatively, we had thought about tagging the existing trail relation with type=provides_features rather than creating a secondary relation, but this would mean losing type=route.

Lastly, it was suggested in the comments that we should consider tagging the car park as being designated for the trail. Though we would be cautious using the term ‘designated’, it would be good to know if there is a tag already in use (similar to bicycle=designated) that could be applied to this scenario.

Thanks again,
National Trust GIS Paths & Trails Team.

12

With my waymarkedtrails’ maintainer’s hat on, let me assure you that this was not the intention of this new feature. Please rewatch the talk I gave at SOTM-EU 2025 to understand the intended purpose.

I understand that your goal here is to outsource all your data storage needs to OSM. And I can only emphasize once more how problematic I find that. OSM should only contain the ground-truth data. Anything else you need to create your website with route recommendations etc. should go into your own database. Your current approach doesn’t scale. Imagine every tourist board, community and travel agency creating their type=provides_features relation. OSM would pretty soon be unusable.

1 Like
13

It’s worth pointing out that the hiking routes put together by the National Trust are widely advertised, signed on the ground (often with coloured waymarkers), put on maps at the car park and in information leaflets. These are not throwaway routes, and they have often been designed around a particular parking/start/cafe location and with appropriate access to amenities like toilets in mind.

To me, for this kind of route, it makes sense to add tagging/a relation/a role to associate parking, toilets, etc. with routes. The location of parking and amenities is one of the first things many people will look for when thinking about walking a particular route.

3 Likes
14

The examples may be attaching points to other points but the table on that page does specifically state that the target(s) can be nodes ways or relations.

I’m not entirely sure what you mean here, it sounds like a lot of explicit mapping for things that might otherwise be implied from proximity. Some, more distributed sites that are mapped with site relations but most of the time it makes more sense to put a boundary line around the whole lot and tag the amenity on the boundary.

15

In my local area there is portal for people having fun in tobogganing. It is called winterrodeln.org and the maintainer even was actively pursuing a proposal for a route=sledge (or the likes) type of relation that would include parking lots, public transport stops and huts/restaurants. At the moment I cannot find the details with a web search. but I remember, the proposals stalled and recently got pulled.

Personally I consider OSM route relations generally very fragile, and anything more than creating a consecutive/ordered from-to path with no loops nor stops along the way even more so.

16

An example overpass query to help search for these sorts of things is this. That version is looking for ways with a building tag that are part of type=route; route=foot relations over a swathe of northern England.

It finds some interesting examples - for example here I don’t think that the toilet building is, like the car parks, really a necessary part of the route. That’s in contrast from the “route starts from the pub” example above where it arguably is “part of the route”.

1 Like