Add information necessary to implement Trails Working Group rendering guidelines

[dschep]

It's currently not possible to implement the Trail Working Group's rendering suggestions with OpenMapTiles because it doesn't expose the informal or operator tags.

The easiest way to support this would of course be to just pass these through to tiles directly (probably only for class=path).

But I could see creating a combined field sort of like brunnel, in part because the specific operator probably doesn't matter for renderers, maybe just informal and set informal=no when an operator tag is set or just the value of informal if that's present. And omit the field when there exists no informal or operator tag on the way.

I chatted with @ZeLonewolf about this a little, and he suggested maybe something in class or subclass but I don't know how OMT feels about breaking changes, given those are already populated for these sorts of ways.

[TomPohys]

Hi, I think that the easiest way could be just to extend the access attribute to "if access=no or access=private or informal=yes" then the value will be access=no.

[dschep]

IMO that's too little information. You certainly couldn't implement the example rendering tree linked.

[pnorman]

I was going to write something about the tree, but then I noticed the top of the page linked

The scope of this project is US public access lands administered by the US Government. However, the principles in this project plan may be applicable to other public lands at the state and local level

OpenMapTiles needs to work everywhere. Their recommendations are built around paths with Land Managers, while most paths don't have a Land Manager in the sense they are talking about. I suspect most footpaths are far more similar to a sidewalk than a footpath on public lands, but would welcome an analysis.

I think two attributes are the best method of doing this. One for access with three possible values - yes (including plain highway=footway with no other tags), sort of, and no access. The other would be surface, also with three possible values - paved, unpaved, or unknown. The cartographer making a style could then choose if they wanted emphasis on access or surface, depending on their needs.

[ZeLonewolf]

I am presently hosting a trails vector layer for OSM US's trail project (the working group and the OpenTrailMap.us map). It's accessible here for anyone that wants to play with it: https://d1zqyi8v6vm8p9.cloudfront.net/trails.json

That's outside of OpenMapTiles of course, but it's fairly easy to generate custom layers for this kind of thing in planetiler.

The schema I've used to generate that trails layer is here.

[dschep]

I think two attributes are the best method of doing this. One for access with three possible values - yes (including plain highway=footway with no other tags), sort of, and no access.

I think that would work 👍

The other would be surface, also with three possible values - paved, unpaved, or unknown. The cartographer making a style could then choose if they wanted emphasis on access or surface, depending on their needs.

This is already there and played a big part in my being able to build V1 of OpenTrailStash! (The field is just blank when unknown) https://openmaptiles.org/schema/#surface

[dschep]

Which, thinking about it, could be implemented similarly to the surface tag. access currently only exists with a value of false. It could be updated to also include true when tags imply access is allowed and remain absent for the "sort of" case. It should(I guess if styles use ["has", "access"] some styles may have a regression) have no impact on existing styles using the access tag but enable better styling going forward.