Render ref= for highway=track and highway=path #2052
Comments
|
Or, more often, only a ref. Not worth sweating whether it's a hex shield On Sat, Feb 20, 2016 at 4:12 PM, msebast2 notifications@github.com wrote:
|
|
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) |
|
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 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? |
|
Pretty much anytime there's a trail, track or tertiary in the national Point is, National Forest Service is strapped for cash and usually only has On Mon, Feb 22, 2016 at 7:28 AM, Mateusz Konieczny <notifications@github.com
|
|
Numerous tracks here in France are subject to this issue: it is common that they have no real name, and are only known as Some examples: https://www.openstreetmap.org/way/411925099 https://www.openstreetmap.org/way/127625664 https://www.openstreetmap.org/way/330787545 |
|
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? |
|
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>
.
|
|
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? |
|
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>
.
|
|
PR #3654 solved this for |
|
Our toolchain has been upgraded, so it is now possible to address this issue and #596 by updating to the latest osm2pgsql master branch. |
|
Note this is still subject to a new osm2pgsql release and its availability on the OSMF servers. |
|
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. |
Not really. It is fine to create partial relation with fixme |
|
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. |
|
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. |
|
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. |
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.
The text was updated successfully, but these errors were encountered: