Keys for relation:route

It has been proposed that this page or section be merged with Relation:route#Tags. (Discuss)

This is a work in progress, please add your proposals and ideas to the page here, or onto the talk page. Also of course the name of the keys is not yet fixed and maybe better names could come up.

The need for differentiation has come a a couple of times (e.g. | Cycle route won't render ). On one side renderers need more differentiation to decide how important an relation is, on the other hand there is a lot of information that is simply not yet tagged or not tagged in a machine readable form.

keys/tags or values that should only be used for Relation:route

• key:incline New Values: Upstream, Downstream -- Usefull especially for cycle routes that follow rivers. I'm not sure if and how this would be implementable as relations in principal have no direction.
  • I don't see this as part of the incline feature. This depends on the relation having ordered ways/nodes, which in turn gives a kind of 'natural' direction. Anyway I don't think, that this is a valuable information at all. Wether it's finally upstream or downstream depends on the direction in which the route is used.
• New key:ascent in m Vertical total ascent over the course of the relation. Useful especially for mtb/cycle/hiking routes.
• New key:descent in m Vertical total descent over the course of the relation - if start and endpoint are not the same, ascent and descent will be different.

• New key:roundtrip to put down whether a route is a roundtrip starting/ending in the same city/place (A-->B-->A) or goes from place A to place B (A-->B). Values "yes"/"no" or is a finer seperation needed/useful?

already established keys/tags and values that should be added to wiki pages like Relation:route or Cycle_routes

• key:distance Missing on many pages in the Wiki. Also we have to work on notation for values and write a wiki page for it. I would propose default unit to be "km" and if alternate unit is used to indicate it by
  • key:distance:unit It's much easier for computers to find out the unit than by using values like xxxkm or xxxmiles
    • There exists an established pattern to handle units, why not use it? In either case, getting the unit requires several string-compare operations. Splitting it over multiple keys requires additional string-compares plus access to table for keys that must be interpreted together. So please don't believe, that one or the other is easier for computers. As a fact, none of both is any challenge for todays or yesterdays computer (the pure amount of data might be for yesterdays computer).
      • Well I think using a different key for the unit is much easier (you can just make a rule IF distance:unit=miles THEN {distance}*factor. - if you put it into one key, you need software that takes numbers and letters apart before you can work with arguments, this is more difficult because you actually need software to intelligently split a value). distance key is not really used yet, so lets avoid making the same mistake as with maxspeed. I only know that mkmgap cannot yet work properly with entries like maxspeed=70mph, but would be usable if unit were in a second key. --Extremecarver 19:50, 17 January 2010 (UTC)
        • If you need it for Garmin, split in composer! --EvanE 01:38, 19 January 2010 (UTC)
          • Osmcomposer is not my type of beer (slow and complicated). Well the functionality will be implementable with Regex, it is simply a bit more complicated than when having two fields.--Extremecarver 09:00, 19 January 2010 (UTC)