Render ref= for highway=track and highway=path

[msebast2]

US forest service roads and trails often have both a name and a Forest Service road or trail number.
It would be nice to have these numbers rendered.

[BalooUriza]

Or, more often, only a ref. Not worth sweating whether it's a hex shield
or a rectangular slat, or whether that slat's horizontal or vertical until
proper shield rendering happens, though...

On Sat, Feb 20, 2016 at 4:12 PM, msebast2 [email protected] wrote:

US forest service roads and trails often have both a name and a Forest
Service road or trail number.
It would be nice to have these numbers rendered.

—
Reply to this email directly or view it on GitHub
#2052.

[matkoniecz]

Can you give examples of ways where such rendering would be useful?

See also #514 (ticket with the same new feature request, closed as it seemed as it would mostly support incorrect rendering)

[msebast2]

Hi Mateusz,

We need to render the ref= for paths and tracks for the exact same reason we render ref= for freeways and highways. Sometimes signs use the ref= designator and sometimes they use the name. So a useful map needs to show both.

For example, if someone was out hiking in the Los Padres National Forest, they might come across this sign:(See attached image)

But today the hiker looks at open street map, and they don't see any trails labeled as 22W08.On open street map this trail is shown as "Horn Canyon Trail".http://www.openstreetmap.org/way/10736646
And we SHOULD show the name "Horn Canyon Trail, because at the other end of the trail is a sign with that name.

Thanks for the link to #514. I'm confused about why it was closed?If I make the path part of a relation will that cause the trail number to get rendered?Should I create a relation that contains only one path and no other ways?
Thanks & Regards,Michael Sebastian

[BalooUriza]

Pretty much anytime there's a trail, track or tertiary in the national
forests of the US. For example and from the best of my recollection (so
don't take it as gospel if you're looking for things to map right now),
let's consider Larch Mountain Trail in the Columbia Gorge National Scenic
Area. If you start at Historic US 30 at Multnomah Lodge, the first
wayfinder you'll see will tell you to head up the lodge's promenade for
#400 Columbia Gorge Trail, #441 Larch Mountain Trail to Multnomah Falls
Overlook, or go back through the parking lot to take #400 Columbia Gorge
Trail, #420 Wahkeenah Trail. So, continue along Larch Mountain Trail, and
the next wayfinder at the first intersection after the concrete promenade
ends and you're on a hiking trail, you'll just get "400" pointing east and
"441" pointing north (though maybe a wayfinder that says "To Overlook").
Go up past the overlook (about two thirds of a mile north northeast and a
thousand feet vertical up) and you'll get to the Perdition Trail, which is
just marked by wayfinders pointing "441" north/south and "421" east. Go
one more intersection (about another mile give or take) and you'll get to
the other end of Wahkeenah Trail, marked just "#420" pointing east, and
"#441" north/south (and possibly a sign warning that you're crossing the
alpine threshold (where snow is routine Oct-May), and that emergency
services will not go rescue you anytime of year on 441 (the lower portion,
particularly below the outlook, is frequented year round by tourists who
just hike from their car because they saw a sign for the falls on the
freeway, the trail continues well past, and about once a year fairly
reliably someone hikes off into the National Forest never to be heard from
for days, if ever again, totally unprepared for the conditions). Continue
far enough along 441 and you start getting into national forest service
development roads ("NFD" tracks) that have 3 (usually above 500) or 4 digit
trail markers, oriented vertically if they can't be traversed with your
average sedan or horizontally if they can, until you finally reach the end
at a parking lot aisle, NFD 560, and if you cross that, you end up on NF 20
in the National Forest highway system.

Point is, National Forest Service is strapped for cash and usually only has
consistent numeric wayfinders for named trails, and some state lands
(Robbers Cave State Park in Oklahoma for sure) have similar, primarily
numerical wayfinders on something vaguely

On Mon, Feb 22, 2016 at 7:28 AM, Mateusz Konieczny <[email protected]

wrote:

Can you give examples of ways where such rendering would be useful?

See also #514
#514 (ticket
with the same new feature request, closed as it seemed as it would mostly
support incorrect rendering)

—
Reply to this email directly or view it on GitHub
#2052 (comment)
.

[Penegal]

Numerous tracks here in France are subject to this issue: it is common that they have no real name, and are only known as rural track #5, exploitation track #6 or village route #12, which respectively makes ref=R 5, ref=CE 6 and ref=C 12 in OSM. Displaying their refs would be a plus, at least instead of names when there are none.

Some examples: https://www.openstreetmap.org/way/411925099 https://www.openstreetmap.org/way/127625664 https://www.openstreetmap.org/way/330787545

[kocio-pl]

Sounds sane, I also know similar tracks in Poland, where name is abused to show ref number. It should be rather easy to code. How should it look like?

[jeisenbe]

I guess they would need to have generic shields, like those used for road ref numbers? This would be quite useful for forest service roads in the USA.

…

On Sat, Dec 1, 2018 at 2:26 PM kocio-pl ***@***.***> wrote: Sounds sane, I also know similar tracks in Poland, where name is abused to show ref number. It should be rather easy to code. How should it look like? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2052 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AoxshEaAar2HgCJzNdzFSm6feVkHJtaqks5u0hLugaJpZM4HewaB> .

[Penegal]

A shield seems overkill to me: such data does not seem important enough to justify a shield and, as the ref is then used as the name of the highway, rendering the ref as the name in such cases would make sense. But maybe it would simply create confusion?

[msebast2]

Hi gravitystorm, I think both the number and name could be very important to someone navigating in remote wilderness areas. Many trails and dirt roads in US national forests have both a name and a number. I have seen cases where the number was used at one end of the trail and the name was used at the other. So both need to be displayed somehow on the map. A very simple shield, like a rectangle with a number in it, would be fine. It would be really cool if this could be done. The situation is analogous to freeways that have both a name and a number. Like in downtown Los Angeles the 101 is also called the Hollywood freeway. The name and a shield with the number are both displayed. Thanks and Regards, Michael Sebastian

…

On Sun, Dec 23, 2018, 8:58 AM Penegal ***@***.*** wrote: A shield seems overkill to me: such data does not seem important enough to justify a shield and, as the ref is then used as the name of the highway, rendering the ref as the name in such cases would make sense. But maybe it would simply create confusion? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2052 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQj5uFevDLvmlpxCkcQ7kqTZijwm-kdDks5u77ZEgaJpZM4HewaB> .

[jeisenbe]

PR #3654 solved this for highway=track
PR #3663 attempted to address highway=path, but it is best if "ref=" tags are placed on route relations for footways and cycleways. This requires solving issue #596 before we can render the ref for paths, which could be done best by improving osm2pgsql. See osm2pgsql-dev/osm2pgsql#230

[jeisenbe]

Our toolchain has been upgraded, so it is now possible to address this issue and #596 by updating to the latest osm2pgsql master branch.

[imagico]

Note this is still subject to a new osm2pgsql release and its availability on the OSMF servers.

[hungerburg]

The closing of #514 this with the instruction to create relations instead misses out on incremental gathering. E.g. I come across a guidepost and see destinations and the branching paths reasonably lie on the advertised route, so I tag the ref number from the guidepost on them.

To create a route relation, I would have to hike the full route. Yet, that is not why I happened over there. Currently the information that I provided is lost on OSM-Carto. It should not be buried until someone decides to create a route relation.

[matkoniecz]

To create a route relation, I would have to hike the full route.

Not really. It is fine to create partial relation with fixme

[imagico]

To be clear - no recommendation as to how to map things has been given here or in #514. It was just said that refs of a path are typically the refs of routes using that path rather than refs of the physical path mapped with highway=path. And because of that we want to focus on solving #596 rather than rendering refs on highway=path and thereby incentivizing tagging route refs on the physical path - with all the problems this comes with - see also #3663 (comment).

If solving #596 means rendering refs from route relations only or also from highway=* ways will need to be discussed for the different highway=* types depending on mapping practice. But that will naturally be a different discussion once we can render the refs from route relations.

[hungerburg]

I am a bit ambiguous, insisting on relations will create lots of single member relations, if not split every 100m for mtb:difficculty of sac_scale or surface|smoothness|trail_visiblity|&c, even those, that are complete, where no fixme=complete_me is required. Should that be incentivized? The bodies that number the ways certainly think of them as ways not routes. But that may have to do with language a lot. A Route is just a verbal account of how to get from here to there, following paths, traversing pathless terrain, you name it.

[imagico]

As i have tried to indicate i have not formed a qualified opinion on if a ref tag should be rendered on highway=path and if - whether it should be rendered from route relations only or also from ways. I have never seen a highway=path mapped where a ref is applied or could be applied to a single way only. But that does not necessarily mean much. I will look at this if and when a decision on this is due.

What we quite definitely won't do is render the refs from ways only and thereby steer mappers to change their mapping practice and tag refs that apply to routes to the physical path way. Given that route relations are a widely accepted way to map route refs on highway=* - see #596 - this is unlikely to change.