Talk:Walking Routes
Contents |
Relations - network key
Can this be marked as optional? I'm not sure it is used on things like The Essex Way. EdLoach 14:20, 19 January 2009 (UTC)
Actually, thinking about it, it isn't international, national or local so I've added network=rwn to the relation. Forget I wrote the above EdLoach 14:31, 20 January 2009 (UTC)
Do we really need 3 tags for the same thing?
Until now I was aware we were using both foot and hiking as route types. Now this page suggests walking for the same thing.
A quick look at tagwatch shows the following count
- foot 650
- hiking 442
- walking 254
So I would rather suggest dropping the least used tag, which would be walking. Having two redundant route types is bad enough. --Nop 17:00, 19 January 2009 (UTC)
In the Netherlands the decision was made to tag using 'walking' as you can have a hiking-route, a walking-route, but a foot-route? Still it's probably best to standardize. --Rene_A 18:10, 19 January 2009 (UTC)
Let's collect some pros/cons then.
| Tag | Pros | Cons |
|---|---|---|
|
route=foot |
|
|
| route=hiking |
|
|
| route=walking |
|
Feel free to append to this list.--Grille Chompa 18:26, 19 January 2009 (UTC)
Walking and cycling route
Some routes here are both walking routes and cycling routes. How would one tag those? --Eimai 18:35, 19 January 2009 (UTC)
- Two seperate relations. The identity may change, also the relation may include different additional points of interest für cyclists and hikers. --Nop 21:05, 19 January 2009 (UTC)
- Yes, but I'd stay away from mixing ways abd POIs in one relation (500 members in 1 relation is more than enough). Instead create two or more relations and then create a relation of these relations. --Keichwa 04:53, 20 January 2009 (UTC)
Rendering considerations
Here's some of my experience from creating a hiking map:
- You should use a route relation to describe your route as this is the direction development is moving in. I consider it unlikely that directly tagged routes will be supported by a renderer as this concept is obsolete.
- You should include a symbol tag in your relation, so someone setting up a renderer has an idea how to include your route. Or maybe an URL to this sort of information. Currently it is a shame that there are many usable looking routes that cannot be rendered as there is no information on their markings. --Nop 16:53, 19 January 2009 (UTC)
- A common tag used in Belgium now is color=red/orange/blue/etc, given that many routes have a specific colour in their signs. This already gives an excellent hint to render routes (see this rendering for example). --Eimai 17:16, 19 January 2009 (UTC)
The symbols
In many countries generalized symbols are in use. I'd like us to work out a formalized description of these symbols that could be read by a renderer engine without human intervention. Somewhere I already saw such a proposal. Here is my proposal (once the syntax is settled, an English native speaker is asked to help with the terms, please):
foreground__background__[text]
where
foreground == color_symbol background == color text == letters or numbers printed on top (optional)
Examples:
- red_bar__white
- a red bar (horizontal) on a white background
- red_bar__white__F
- a red bar (horizontal) on a white background with a "F" letter on top
- white_2__green
- the white number 2 on a green background
I'm wondering whether we must distinguish between a description of the symbol and hints to the renderer? --Keichwa 05:17, 20 January 2009 (UTC)
- Yes you must. Such a code will be highly renderer specific - if the renderer does not know or cannot display any part of the syntax, the mechanism is broken. Or incomplete, e.g. your proposal is missing a part that the hiking map renderer would support. There are also many non-standard symbols that cannot be described this way but that may be approximated, but only if at least the human adjusting the renderer has any idea what is intended (examples). E.g. currently I am using a black X in one case to approximate the symbol of crossed hammer and axe.
- But most importantly: Many people will take the time to enter a freeform human readable description, but will not want to learn the syntax of a particular renderer and formulate an exact technical description. Remember the discussion on talk-de about names. If some people are not even willing to take the time to research the proper name for a route (which is quicker than getting familiar with a renderer syntax and checking the list of available markings), they'll never supply a renderer description. But most of those relations already have the symbol description, just mislabeled as a name. --Nop 07:57, 20 January 2009 (UTC)
Where's the syntax for this? What would this for example be in this scheme? It doesn't have a background color... --Eimai 12:21, 22 January 2009 (UTC)
- Note: For the hiking map, there is a similar scheme for renderer directives already implemented and working. (Discussion page is in German, concept is language independet) --Nop 11:15, 26 January 2009 (UTC)
state=proposed
Perhaps status=proposed may be better, having read the comment on the main page? EdLoach 14:35, 20 January 2009 (UTC)
- But state=* is already used a lot for the cycling routes, so it makes sense to follow that scheme. There's also state=alternate and state=connection in use btw. --Eimai 11:28, 21 January 2009 (UTC)
Can you explain the context of this tag a little? All the hiking routes I know in Germany are marked and kept by organizations like hiking clubs or local tourist offices. The authorities don't care about hiking routes and hiking routes have no legal impact. So I do not understand what the concept of a proposed route would be. --Nop 11:51, 21 January 2009 (UTC)
- I personally don't know a proposed walking route here, but there's for example a proposed cycling route: the signs are (partly) there, but it's route is taking a ferry which will only be opened in several months. --Eimai 12:07, 21 January 2009 (UTC)
Merge with Hiking?
See Talk:Hiking#Merge with Walking Routes? -- Harry Wood 01:01, 26 January 2009 (UTC)
moved User:Nop's comment to the right place