User:Martinq/tagging schema

Objective

An analysis of the current structure of tag names with the objective to identify (different) underlying naming patterns. Relations are not included in the investigation.

Basic terminology: Objects and attributes

The OSM database describes physical objects in the world (and a few logical ones). Following aspects can be separated:

• Type of object (what it is), which is described by tag(s)
  • Examples: highway=*, building=*, railway=*, waterway=*
• Geometry defined by nodes, ways or area (closed way) where the "object" tag is attached to
• Attributes to the physical objects (=their properties), also described by tag(s)
  • Examples: width, maxspeed, maxwidth, lanes, tracks, electrified
  • access is also an attribute (of the building, highway, etc).

Conditions (for attributes)

It turned out pretty quickly that attributes have different values under different conditions, for example a maxspeed in forward direction may differ from the backward direction, may be different for trucks (HGV) or from 22:00-5:00. Thus tagging must include a further aspect:

• Conditions defining the validity of an attribute
  • Example: bicycle, bus, psv, motor_vehicle limit the attribute to a specific vehicle type
  • forward and backward restrict to a specific direction
  • hour_on/off to a specific time of the day
  • For details about the tagging patterns when used in combination with attributes -- see section on conditions

See also:

• Proposed_features/Conditions_for_access_tags
• Proposed features/Extended conditions for access tags
• Proposed features/access restrictions 1.5

Object selector

Where one node/way/area can contain several objects of the same type, for example one road can have two sidewalks, it is necessary to identify a specific object, for example the left or the right sidewalk.

• Selector allows identification of individual objects of the same type
  • Example: :left and :right

Object tags

For describing the object itself (the object type/class), following tagging pattern seems to be pretty common:

• object_name=yes if the node/way/area represents this object, without further classification or type
• object_name=classification/type where classification or type is typically further describing the kind-of object.
• classification=sub_classification is used for more detailed specification - and allowing at the same time a limited number of top-level types/classifications.

Examples that match:

• highway=service + service=driveway
• building=yes
• building=house + house=semi-detached [4000 uses]
• railway=tram
• bridge=yes
• barrier=gate

Deviations from this schema:

• highway=yes - not described -- for legacy reasons it looks like that highway=road takes this role
  • However, it seems to be logical/intuitive for mappers and it is used 150 times
• sidewalk=left - left, right, etc. is not really a kind-of or type

Attribute tags

Originally attributes didn't have a prefix for the object, mainly because a node/way/area was typically one object identified by object (type) tags and it was obvious that the attribute tag refer to this object.

Nowadays a single way describes several physical objects, for example highway, sidewalk, cycleway, parking:lane, barrier, embankment. Thus it would be unclear if for example width is related to the parking lane, the cycleway, the sidewalk.

The main pattern found is the object prefix: object_name:attribute=value

Examples:

• building:levels
• cycleway:width

For historical reasons, highway prefix is omitted (maxspeed and not highway:maxspeed).

Attributes with conditions

There is still no universal tag scheme, because conditions can get rather complex (attribute value applies to HGV, but only every second Sunday if the destination is north to Mordor).

attribute:condition

'Old' conditions:

• hour_on/off, day_on/off, date_on/off -- for time
  • Pattern: The condition applies to the attribute without the postfix. attribute=value plus attribute:hour_on, attribute:hour_off must be used.
• vehicle types (see access=*)
  • Pattern: attribute:condition=value, value applies only for the specified vehicle
• forward and backward
  • Pattern: attribute:forward=... and attribute:backward=...

Examples:

• maxspeed plus maxspeed:hour_on and maxspeed:hour_off
• maxspeed:hgv
• maxspeed:forward

Deviations:

• If the access=* attribute is restricted for a vehicle, then for example access:vehicle would be consistent with the pattern. For legacy reasons the access: prefix is omitted and only vehicle=... is used.

Limitations

• For one attribute only one value can be defined if time restricted
  • maxspeed=80
  • maxspeed:hour_on=22:00:00
  • maxspeed:hour-05:00:00
  • How to define maxspeed=100 for the other times?
• Missing flexibility
  • Wet or other weather conditions, maximum height, just with those with permit A38 - how to limit attributes to these conditions?

There is no widely accepted solution yet, but proposals:

• Proposed_features/Extended_conditions_for_access_tags extends the principle of putting the condition into the key (attribute:condition) and is also suggesting to replace hour_on, etc by opening_hour syntax, resulting in keys like maxspeed:(Mo-Fr 07:00-17:00).
• Proposed_features/access_restrictions_1.5
• Puttng the condition into the value

Links

• forward/backward
• WikiProject Semantics
• Data_Primitives
• User:Joto/How to invent tags