In California, the Pacific Crest Trail and the Tahoe Rim Trail are two well-known trails that merge together for several miles on the west side of Lake Tahoe, and then separate again. Since both are well known trails, I believe the proper rendering is to show both names on the map. How can this be achieved in openmap? How does the renderer know to display both names if using "alternate" names?

Here is the section on openstreet: https://www.openstreetmap.org/#map=16/39.1084/-120.2363&layers=C

Currently, the name has been set to "Pacific Crest Trail (TRT)", where TRT means Tahoe Trim Trail, but that is not ideal. First, users may not know the TRT abbreviation. Second, a "Tahoe Trim Trail" search will return empty result for that segment. Third, this means the data is denormalized. Setting the name to "Pacific Crest Trail, Tahoe Trim Trail" may be too long.

GraphHopper shows both names when using the "TF Outdoors" layer: https://graphhopper.com/maps/?point=39.104422%2C-120.235448&point=39.12793%2C-120.225964&locale=en-US&vehicle=foot&weighting=fastest&elevation=true&layer=TF%20Outdoors

asked 29 May '16, 18:00

srosset's gravatar image

srosset
46114
accept rate: 0%

edited 30 May '16, 00:01

aseerel4c26's gravatar image

aseerel4c26 ♦
32.0k16238549


OSM is about the data - not what specific maps make of it.

Hence, those two trails (both are routes which are several miles long and extend over many OSM ways and way junctions, right?) should be mapped as single routes. At the part where both trails "join", the relevant OSM ways will be a member of both route relations. The OSM ways themselves (e.g. https://www.openstreetmap.org/way/235015476 ) should not bear the name of any of these routes (instead these ways could have their own name, if they have any).

In fact, both trails are already mapped as relations:

A renderer then could display names (or shortcuts or symbols) for both routes (trails). This is likely (I am just guessing) what TF Outdoors does (since it is also based on the same OSM data).

permanent link

answered 29 May '16, 19:10

aseerel4c26's gravatar image

aseerel4c26 ♦
32.0k16238549
accept rate: 17%

edited 29 May '16, 23:20

Thanks for the answer. The data is useful so far as renderers use it. Hence shouldn't the data be set knowing how most renderers will use that data? That will make the maps more useful for everybody. If the data is in OSM but not rendered, planning a route (especially outdoors) is doable but much more difficult. I know several people who gave up too quickly on OSM, partially because the data is not rendered in a user-friendly way. Yes, there is a great ecosystem of renderers, but many people who are introduced to OSM for the first time wouldn't even realize it, which is too bad give how great OSM is.

The current relations do exist, but they are not rendered optimally in openstreetmap.org, so I was wondering if there is a better way to tag the data.

For this specific segment, the MTB data provided by the Tahoe Trim Trail (https://www.tahoerimtrail.org/index.php/trip-planning/planning-details/mountain-biking) does not match the data in openstreetmap. I am assuming I need to ask the TTR for permission to update OSM based on their data.

(30 May '16, 02:32) srosset
4

You write "but they are not rendered optimally in openstreetmap.org, so I was wondering if there is a better way to tag the data." In OSM that is considered "tagging for the renderer" and is highly discouraged.

The better course of action is to point out that area and the rendering issue with the maintainers of which ever map you would like improved.

(30 May '16, 02:41) stf
5

@srosset The data is not only used by renderers but also by routers, geocoders and various other tools. That's why certain rules should be followed to keep the data usable for more than just a single purpose.

(30 May '16, 07:40) scai ♦
4

That will make the maps more useful for everybody

No, it will make the maps more useful for people who view the default rendering on openstreetmap.org, at the cost of being less useful - or possibly even broken - for people who view different renderings elsewhere, use routers, geocoders and so on. People viewing on openstreetmap.org are probably by now a minority of those using OSM data. In any case, this is a long-standing principle in OSM, please don't try to reinvent it 12 years into the life of the project!

(01 Jun '16, 09:36) Richard ♦

Hi

I have been struggling with best practices for name tagging ways. As an example please view the 1779 Trail on which I have worked which is shared in part by the 1777W Trail, the Timp Torne Trail links included below.

What I have done here is

  • created a relation for each of the individual trails adding the name of the trail to the relation name.
  • leave the name tag on the way blank.

However a problem arises: On waymarked trails this portion of the trail is rendered as follows: http://hiking.waymarkedtrails.org/#route?id=6292324&map=18!41.3237!-73.9884 showing symbols for the 3 trails that the way.

On openstreetmap.org it is rendered as follows: https://www.openstreetmap.org/#map=19/41.32387/-73.98884 showing neither the symbols or the 3 associated trailnames.

I am wondering if it would make sense to have the default openstreetmap.org page render the name tag of each associated relation on hiking trails and if there are no relations then render the name tag of the way itself? This would be very helpful for people like myself who start on OSM knowing nothing with no-one there to guide us. If we saw the relation name tags rendered on the default osm page and then in editing that path we saw that the way has no name, we would understand better the best convention. In addition it would help overcome the urge to add a name to a way because we don't see it in the default osm window even though the proper names are there in the relations..

Bill

permanent link

answered 25 Jul '16, 23:18

will-i-am's gravatar image

will-i-am
111
accept rate: 0%

edited 26 Jul '16, 06:24

aseerel4c26's gravatar image

aseerel4c26 ♦
32.0k16238549

@will-i-am: just for reference: link to the way in question https://www.openstreetmap.org/way/432825147 . Showing hiking routes: Well, the default map also does not show cycling routes and bus routes for example. I understand your thoughts about it, and share them partly. However, it might make the map very cluttered if it would show all routes, so that might be a deliberate setup. Th option to only show the routes in the highest zoom level (as it is done for waste bins and park benches) would not make much sense - as oppose You could make a suggestion at the standard style's github issues page (but check the old issues for duplicates first and link here once you've created a new issue).

(26 Jul '16, 06:35) aseerel4c26 ♦
2

I am wondering if it would make sense to have the default openstreetmap.org page render the name tag of each associated relation on hiking trails and if there are no relations then render the name tag of the way itself?

There's certainly an argument for that, but unfortunately it's technically very difficult at present. https://github.com/gravitystorm/openstreetmap-carto/issues/596 is essentially the issue.

(26 Jul '16, 13:16) Richard ♦
1
(26 Jul '16, 14:34) SomeoneElse ♦
-7

I'm sure that is the correct answer, but I have not been able to be that purist. I give the shared ways a combination name like "Red Trail / Blue Trail", in addition to joining them to both relations.

Common where I map is a trail coinciding with a 'track' - typically an old forest road, unpaved, named but without actual name signs on the ground. In that case, I name the shared way "Whatever Road (Red Trail)", and join it to both relations.

(If a trail segment shares a way with a real road, the shared way gets only the road name.)

Yes, I know the first 2 cases above are 'wrong', and sites like waymarkedtrails.org will display the routes correctly using only the relations, not the way names. But in reality, people do look at openstreetmap.org to try to follow trail routes, and this makes it a lot more usable.

permanent link

answered 29 May '16, 22:42

ljb_nj's gravatar image

ljb_nj
61491726
accept rate: 12%

5

In other words, "I know this is wrong, but I do it anyway." That seems to fall under vandalism (knowingly bad edits).

(30 May '16, 09:44) Piskvor

There is a footway, that is part of two (or more) named hiking trails. Or a track, that is part of a named hiking trail and a named old forest road (although the road name sign is probably long gone). On OSM, the way that represents that shared segment of the footway or track is given a name that represents the reality on the ground: "Red Trail / Blue Trail", or "Forest Road (Green Trail)". That's it's name. By what possible definition would that be vandalism?

(31 May '16, 21:37) ljb_nj

@ljb_nj: I would not say that it is vandalism. However, since you know that the "red"/"blue" trail names/markings do not belong to the footway or track but to a long route, you should not tag them on the footway or track. It is also obvious in reality that those markings do not belong to the single footways or tracks. And, by the way, what's the name of this track (note the route relations of which it is part of)? ;-)

(31 May '16, 22:33) aseerel4c26 ♦
3

If you were to make such edits repeatedly; then someone came along and corrected your edits back to the correct way of doing it; then you reinstated your edits; then, ultimately, your edits would be likely to be reverted and a block placed on you editing the map. I hesitate to use the emotive word "vandalism" but it's certainly contra to accepted and agreed practice within the OSM community.

(01 Jun '16, 09:38) Richard ♦
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×824
×178
×30
×27
×25

question asked: 29 May '16, 18:00

question was seen: 2,015 times

last updated: 26 Jul '16, 14:34

powered by OSQA