Render tracks, paths, trails

[adamfranco]

This is an overview issue to capture ideas and plans for rendering tracks, paths, and navigable ways that are not part of the general-purpose highway network.

While land-access tracks that may be utilized by motor-vehicles and single-track paths are somewhat different, they overlap in that both vary greatly on:

• Access restrictions both overall and mode-specific.
• "difficulty" (e.g. tracktype and/or smoothness for difficulty of motor vehicles accessing tracks, or sac_scale and/or mtb:scale for hiking/biking difficulty.
• visibility (trail_visibility) as these often less-maintained ways age into abandonment. "Informal" paths may fall into this bucket or their own.
• A variety of surfaces from mud and sand to gravel and asphalt.
• Inclusion in recreational networks.

A first step is to identify which dimensions of variation this style will ultimately support and what visual language might be used to show each dimension.

Some kickoff questions:

• How will tracks and paths be disambiguated from each other and from general-purpose roads? (e.g. single line of dashes versus double line of dashes a la USGS topo maps? Different line weights a la Carto?)
• Which dimensions (above, and others?) will be distinguished?
• Will sidewalks, cycleways, and other very-improved infrastructure share the same visual language as other tracks and trails or will they have a divergent representation?
• Will tracktype=grade1 (and grade2?) be rendered more like minor roads or more like worse tracks?
• How might this style assist the work of the Trails Working Group? For example diminishing the visual weight and/or not recommending the use of informal, discouraged, illegal, or dangerous trails.

[adamfranco]

Here are some examples from my map collections. Other examples welcome.

Green Mountain National Forest map published by the US Forest Service:

Note the use double-dashes for tracks and the single dashes for trails. Uses a distinct color for trails of note (in this case the Long Trail and the Appalachian Trail).

Adirondack High Peaks Region

1983, Plinth, Quoin & Cornice Associates

Uses two weights of brown lines for tracks and gray lines for trails. Trail ownership (and/or access?) as well as access modes are indicated by symbols along the line.

Benzie Map & Guide

Published by the Benzie County (MI) Chamber of Commerce. Produced by Michigan Maps Inc, 2006.

Casing and fill is used for snowmobile trails, then colored access-mode dots are used for summer access (the snowmobile trails are multi-use trails in the warm months). The same style of dots is used for hiking/sking paths as well).

Moosalamoo Outdoor Recreation Map

Published by the Moosalamoo Association

Note how the the different access mode dots & dashes get alternated to indicate which are allowed on each path.

Pensylvania Tourism and Transportation Map (2015)

Publish by the PA Department of transportation

No tracks displayed, red dots are used for selected trails (e.g. Appalachian Trail).

Vermont Official Road Map and guide Vermont Attractions

Published by the Vermont Attractions Association

Note the use of green lines (instead of black) for "Recreational Highways". In this case these are US Forest service routes, some of which are tracks of varying grade.

[ZeLonewolf]

It hasn't been explicitly stated, but I would like to see us firmly distinguish paved from unpaved when rendering these classes of features. This could be a bit challenging when considering the current rendering for unpaved roads.

Regarding tracks, I would be okay with some level of unification between them and paved (grade1) and unpaved (grade2-5) renderings of our lowest road classes. The difference between some of these concepts are already so fuzzy that I'm not sure how much we want to visually distinguish them, though I recognize I may be in the minority on this point.

[adamfranco]

I could see paved (grade1) tracks rendered similar service-roads, but with brown casing instead of black. That might be too subtle a distinction though... Similarly tracktype=grade2 with a smoothness <= bad could be rendered like unpaved highway=service, but with brown casing and brown "unpaved" dashes. These tracks should be physically traversal by normal cars most of the time, but still aren't part of the general-purpose highway network. Alternatively these could be rendered more like other tracks with some indication of their good quality.

Differentiating between paved and unpaved footways/cycleways would also be nice.

[adamfranco]

More feedback in the Slack thread...

Bob G (rjgambrel):minnesota: 13 minutes ago
I do not plan to add github to my quiver of communication channels so am providing one reaction to the issue here. Hopefully this will be OK. The specific issue: Will sidewalks, cycleways, and other very-improved infrastructure share the same visual language as other tracks and trails or will they have a divergent representation? Opinion: hardened (paved) cycleways should definitely be rendered somewhat prominently. More so than unpaved paths, hiking trails, tracks, snowmobile trails, grassy x-c ski trails and the like. This does not have to be a full blown CYCLOSM type rendering, but must include any highway=cycleway. Regarding "sidewalks". I feel less strongly about this but possibly all highway=footway with a hardened surface should also be rendered (differently from cycleways though and less prominently). I don't think footway=sidewalk should be rendered until zoomed WAY IN. (I am basing this on the way I map: a footway next to a street gets footway=sidewalk; one that is not next to a street does not). Here is one more thought about cycleways. As you zoom in, cycleways that are part of a route network should render first, then as you zoom in further all cycleways should be rendered. (And if you want to take this a step further, use the network type -- rcn, etc) to determine zoom level to start rendering.) My two cents.

[1ec5]

Typically, both road maps and outdoors maps show trails to a certain extent, but road maps emphasize road classification (and other road attributes) over trail classification, while it’s the reverse with outdoors maps. We could certainly deemphasize road classification at high zoom levels, where it would be less relevant to pedestrians, but should we also try to minimize the number of line treatments for roads at lower zoom levels, to accommodate all the distinctions needed for trails?

By the way, #215 introduces a broken line treatment for roads under construction. I think it’s possible to distinguish between that and broken lines for trails, but we would need to give trails a different line width or color for it to be an effective distinction.

[ahallification]

Would there be any support for rendering natural=peak ahead of other natural/hiking related features?

When exploring large areas of wilderness in the demo the only reference points become rivers and protected boundaries. Adding peaks is a lot more straight forward than some of the features that have already been included, and peaks are included in the majority of maps I've seen. If there's support, I can create an issue and write down some of my thoughts at a conceptual level. The technical side I'll leave to the pros.

[adamfranco]

I'd support peaks before or after other features. Fine to create an issue to start planning. It would be helpful to collect images of various American maps as examples of how they are shown. I don't have a sense if implementation will need to wait on a more cohesive POI rendering structure or if we can just add it in alone.

[1ec5]

Let’s track peaks (and anything other than trails) in a separate issue. After all, it’s easier to implement multiple disparate things at once than to discuss them in the same unthreaded issue.

[ahallification]

Will do. I started writing something up but it was more complicated than I originally expected to get my thoughts down. It’s still forthcoming though

On Sat, May 28, 2022 at 2:31 PM Minh Nguyễn ***@***.***> wrote: Let’s track peaks (and anything other than trails) in a separate issue. After all, it’s easier to implement multiple disparate things at once than to discuss them in the same unthreaded issue. — Reply to this email directly, view it on GitHub <#216 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJRYSRVZPDW25ASL5E6NH3VMJQ7DANCNFSM5QDVDO7Q> . You are receiving this because you commented.Message ID: ***@***.***>

-- Alex Hall | ***@***.***