Hiking/Trails

This article contains a few ideas how tagging of hiking trails can be improved. The proposal extends existing route relation and guide post proposals with new features.

Trail symbol/colour

The relation:route proposal describes few tags that can be used to specify preferred route rendering (symbol=* and colour=*) and route properties (name=*, operator=* and ref=*). The tags has following problems:

• They don't support every possible rendering. For example learning trails are usually rendered as green dashed line in Czech Republic.
• They don't exactly describe type of trail. Only general tags like foot=nwn are supported.
• They describe rendering instead of semantics. For example green dashed line with green strip in white bar symbol instead of trail_type=learning.
• Mapper might use sligtly different rendering for the same type of trail leading to inconsisent map

In my opinion the best way to handle hiking trails would be tagging schema that can describe all properties of the trail. Renderers would select the best rendering based on provided semantics tags. Unfortunatelly there are many trail marking system in the world so making tagging schema that can describe every trail would be really difficult and the resulting schema would be probably really complicated.

I suggest to use different tagging schema for every country/region instead. It should be easy enough for local mapping project to decide on schema that suits well trails in their country.

For example, typicall trail in Czech Republic can look like this:

network=cz:kct
colour=green (note: colour is part of the semantics)
trail_type=major

Problem is that renderers doesn't know how to render the trail. It is possible to modify rendering rules every time somebody decides on new hiking trail tagging schema but that would be too impractical. I suggest to use some method to describe how trails should be rendered that can be used by all renderers and which doesn't require special knowledge from people trying to add new rendering.

I think wiki page similar to kosmos rules can be good for the job. It's easy to understand and easy to parse by renderer. XML file generated from wiki page can be provided to make processing of rules even easier for renderers.

As fallback there still will be tags that describe trail rendering directly. Following tags may be useful:

• symbol - either url or name of symbol saved in OSM svn repository. I'm not sure which one is better.
• line-colour
• line-style

Those tags are intented for trails that are not part of bigger network so it's not worthy to add rendering rules for them.

Extra tags

Following new tags might be useful for hiking trails:

• distance=* real distance (can be quite different from distance calculated as sum of all ways because of hilly terain, curved path etc)
• time=* usuall time required to walk the trail. It's on guidepost in some countries

Composited trails

One trail can consist of multiple shorter trails. This can be useful for example when:

• trail is too long
• tagger wants to tag distance/time of trail segments, not only time/distance of the whole trail
• trail consist of other trails (for example European hiking trails consist of local trails)
• trail has excursions to viewpoints or other importatnt places
• trail have some longre/shorter variants for some its parts

Segments

Segments are members of composited trail that are not complete trail when used alone. Segment can be for example part of trail between two guideposts. Differencing between segments and trail is useful for example on listing of trails in local area. Segments shouldn't be shown on the list, compared to for example local trails that are part of European hiking trail.

Segments can use the same tags as trails. In addition they must have member named parent which points to composited trail they are part of. Segments doesn't have to copy tags for parent trail, parent values are used by default. If both segment and parent trail have the same tag, then segment's value is used.

Guide post

See http://wiki.openstreetmap.org/wiki/Proposed_features/Guidepost

I suggest to extend guidepost with information about trails to guidepost destinations. Two relations will be used. One for guidepost itself, second for every available destination.

The extra informations are provided to make mapping of trails easier by allowing some software tool to show guidepost which are known to have some unmapped trails.

Main guidepost relation

Tags

Key	Value	Explanation
type	guidepost

Members

Type	Role	Recurrence	Description
	location	one	node where guidepost is actually located
	destination	zero or more	relations describing destinations (relation with type=guidepost_destination)

Guidepost destination relation

Tags

Key	Value	Explanation
type	guidepost_destination
name	destination name	Name of destination. Necessary only if member with role destination is not available
distance	value in km	Distance to destination. Necessary if trail to destination (members with role path) are not available.
time	time in hours:minutes	Time required to get to destination. Only if shown on guidepost, no random guesses

Members

Type	Role	Recurrence	Description
	destination	zero or one	Guide post relation at destination (relation with type=guidepost)
	path	zero or more	trails leading to destination

Note that members with role destination and path are not mandatory. The idea is that when mapper finds new guidepost then he will add all destinations with no path and destination members. Later some software may show that there is trail beetween two guideposts which is not mapped.