Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for functional roles #356

Open
pelderson opened this issue Jun 17, 2020 · 2 comments
Open

Add support for functional roles #356

pelderson opened this issue Jun 17, 2020 · 2 comments

Comments

@pelderson
Copy link

The proposal https://wiki.openstreetmap.org/wiki/Proposed_features/Recreational_route_relation_roles has been approved. We would very much appreciate support for the now established basic roles in WMT. My own preference for rendering would be just a slightly different line rendering for the non-main members, so no difference between the roles. They are all variants, usually rendered on route maps as a dotted or dashed line of the same colour as the main route.

I see a rendering problem with the already dotted combination lines when different colour lines use the same ways, but I lack the imagination to find a solution there! Luckily renderers are far better at this than I will ever be. Rendering is just not my thing!

Please note there is a potential issue with the roles forward and backward, very common roles in bidirectional bicycle routes. Combinations of roles were not part of the proposal, and a solution has not been established. A similar issue arises when an excursion has an alternative of its own. The proposal basically says to avoid the tagging issue by using the new roles on relation members, not on way members, but that doesn't solve the problem for the data user! Sorry about that.

@mikehaertl
Copy link

mikehaertl commented Apr 18, 2022

I'd like to make a first proposal for how to solve the rendering:

For all non-main roles, i.e. alternative, excursion, approach and connection:

  • don't let them inherit the osmc:symbol from their parent superroute
  • don't render them at lower zoom levels to make the main route more obvious

Take for example the Goldsteig in Germany:

https://www.goldsteig-wandern.de/

The main route (Yellow S) goes basically from Marktredwitz to Passau and splits in the middle in 2 variants "Nordroute" and "Südroute". In addition there's a mass of approaches ("Zubringer") and other routes, all marked with a blue "S" and all part of the "Goldsteig"-Network.

I've reorganized the main routes into superroutes to make this more obvious. So the main "Goldsteig" superroute now contains 3 sub-superroutes for "Oberpfälzer Wald", "Nord-" and "Südroute". It also contains all the extras (Zubringer, etc.).

If you look at the WMT map it's not at all obvious where the main route is:

https://hiking.waymarkedtrails.org/#route?id=61186&type=relation&map=9.0/49.3456/13.2114

And all the side-routes inherit the "yellow S" from the main superroute even though that's not how they are marked at signposts.

What do you think?

@mikehaertl
Copy link

More suggestions:

  • The non-main roles should also not inherit the network from the parent

In the example above the main route is marked as nwn and the rest (Zubringer) as rwn or lwn. But the side routes are also rendered as nwn.

In general I wonder what's the idea here: Why do superroute elements always inherit e.g. the osmc:symbol even when they are tagged with their own symbol? I would expect that this only happens if a sub-route does not have osmc:symbol. But if there is such a tag on a subroute it should always "win" over the parent. This affects not only the new functional roles but any superroute.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants