User talk:Steve Hill

From OpenStreetMap Wiki
Jump to: navigation, search

Tagging Overhaul

The Problem

The current tagging methods produce data which does not contain very obvious contextual information since the object type and object attributes are mixed together. For example, consider the following two ways:

  • natural=cliff, rock=limestone, height=25
  • climbing=route, rock=limestone, height=25

Are both these objects of the same type (rock=limestone), or is one describing a cliff and one describing a climbing route? Without prior knowledge of the tags used, it is impossible to tell which tags are describing the object type, and which are merely describing attributes of the object.

Additionally, a tag does not necessarily have a single globally defined meaning, which means you must know the context in order to understand it. This is especially important when doing things like looking up the meaning of tags in the wiki.

Also, things start to become a problem when an object if of more than one type - for example, a way which is a road during the summer and a piste during the winter. If the way is tagged as both a road and a piste, how do you know which attributes are relevant to the road and which to the piste? A prime example would be the "name" tag - the piste may well have a different value to the road.

A Solution

The current tagging system used for relations offers a solution - a designated "type" tag. By extending this idea, it is possible to produce a tagging scheme that separates the context from the attributes and can be applied equally to both relations, and to the underlying objects.

So, we could tag a way thusly:

  • type=road, classification=tertiary, name=Foo

Or, in the case of an object that has a number of different types associated with it, rather than tagging the object itself, a relation can be created for each type and the same tagging scheme used to tag the relation:

  • Relation 1: type=road, classification=tertiary, name=Foo
  • Relation 2: type=piste, difficulty=easy, name=Bar

Example Tagging Scheme

Key Values
type road
classification motorway, motorway_link, trunk, trunk_link, primary, primary_link, secondary, tertiary, unclassified, service, track
name *
gradient 10%, 20%, 30%, etc.
crossing ford, bridge, tunnel
traffic_calming bump, chicane, cushion, hump, rumble_strip, table, choker
smoothness excellent, good, intermediate, bad, vary_bad, horrible, very_horrible, impassable
surface black_top, concrete, brick, slab, cobble, dirt
type piste:downhill
name *
difficulty novice, easy, intermediate, advanced, expert
lit yes, no
abandoned yes, no
grooming_priority 1, 2, 3
type piste:nordic
name *
difficulty novice, easy, intermediate, advanced, expert
grooming classic, skating, scooter, backcountry
lit yes, no
abandoned yes, no
grooming_priority 1, 2, 3
type piste:sleigh
name *
lit yes, no
abandoned yes, no
grooming_priority 1, 2, 3
type piste:sled
name *
lit yes, no
abandoned yes, no
grooming_priority 1, 2, 3
type piste:snow_park
name *
lit yes, no
abandoned yes, no
grooming_priority 1, 2, 3
type aerialway:cable_car, aerialway:gondola
name *
occupancy (Number of people per car)
capacity (Number of people per hour)
duration (Number of minutes the lift takes to go between stations)
type aerialway:chair_lift
occupancy (Number of people per chair)
capacity (Number of people per hour)
duration (Number of minutes the lift takes to go between stations)
enclosed yes, no
heated yes, no
type aerialway:mixed_lift
name *
chair_occupancy (Number of people per chair)
gondola_occupancy (Number of people per car)
capacity (Number of people per hour)
duration (Number of minutes the lift takes to go between stations)
enclosed yes, no
heated yes, no
type aerialway_pylon
ref *
type ski_lift:t-bar, ski_lift:j-bar, ski_lift:platter, ski_lift:rope_tow, ski_lift:magic_carpet
name *
capacity (Number of people per hour)
duration (Number of minutes the lift takes to go between stations)
type ski_lift_pylon
ref *
type station
name *

Discussion

Please add discussion points below. :)

Looks great, Steve. How about for natural areas:

Key Values
type natural
classification water, farmland, forest, sand, rock, mountain, scrub, meadow, prairie, bog, tar_pit, glacier, swamp
name *
wheeled_navigable yes, no
min_wheeled_type none, 4WD, 4WD_high_clearance

actually I am not so pleased by the idea to have an relation for almost every object. What do you think about hierarchical tags? Like in the address-scheme you could apply (and there are quite a bit of proposals in the wiki for this) tags in namespaces: in the case of your Piste this could be: instead of

type=piste, difficulty=easy, name=Bar

you use:

piste:difficulty=easy
piste:name=Bar

--Dieterdreist 23:07, 20 February 2009 (UTC)


You don't need a relation for almost every object - only those objects which share a geometry (e.g. a road that is also a piste, etc.) Steve Hill 09:28, 23 February 2009 (UTC)