Talk:Walking Routes

From OpenStreetMap Wiki
Jump to: navigation, search

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

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

  • analogy to route=bicycle
  • analogy to other tags: foot=yes, footpath
  • most widely used tag
  • doesn't allow to differentiate between city-wide walking routes and cross-country or hilly hiking trails
  • not intuitive
route=hiking
  • most intuitive term
route=walking
  • misleading, in Germany walking means "nordic walking", not hiking

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:

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

Personal tools
Namespaces
Variants
Actions
site
Toolbox