Relations/Proposed/Defaults

defaults
Status:	Draft (under way)
Proposed by:	FrViPofm
Tagging:	type=defaults
Applies to:	relation
Definition:	Relation for defining default values
Rendered as:	Not rendered
Draft start:	2010-05-28
RFC start:
Vote start:
Vote end:

As the author of this proposal is not very skillful in English, corrections to this page are welcome. Discussion may take place on the talk page.

Contents 1 Why defaults? 2 Tags 2.1 Syntax 3 Members 4 Questions to be resolved 4.1 Syntax 4.2 Loops 4.3 Collision 5 Examples 6 List of existing defaults relations 6.1 France 7 Notes & Links

Why defaults?

There are, for the same kind of objects, several default values at the country or lower administrative level (e.g. state, province, county, city). These include things like speed limits and holiday periods. Routing engines currently need to retrieve these defaults from other sources, which can be difficult to code, and of varying availability, timeliness, and quality.

It has been suggested somewhere that an XML file could be written to store those default values for renderers, routing engines, etc. It seems easier to insert those metadata into the database in a special kind of relation.

This is the aim of the relation type defaults. This relation can be added as a member of other relations with a role of defaults.

In this way, the default values are:

• Easy to create and update
  • The default values are gathered in an object
  • The syntax is clear and easy : def:conditions;new tag = default_value and permit complex constructions such as def:condition1&condition2;new tag = default_value
  • The semantic is the common one + def
• Highly available
  • Referred to by the defaults member in any relation
  • Embedded inside the OSM data in .osm format
  • "Just in time" for the engines, routing systems, etc.
  • Easy to get via the API for map builders (like Garmin...). An engine that would have "hard-coded values" would be considered as obsolete.
• Easy to use - the default value is for areas inside boundaries
  • The apply_to role in the default relation defines the scope of its values
  • The admin_level of the boundaries indicates the priority of values to apply (smaller areas with numerically higher admin_level values supersede larger areas)

Note: The "defaults" are not tags that would apply to the object itself but instead to objects contained in its area. So, a timezone or a currency that are properties of a country or a state should not be tagged using defaults, for they are not default values inside this area, but values of this area.

Tags

Syntax

The proposed syntax for a default tag is in three parts:

• A keyword def followed by :
• An optional set of conditions separated by &^[1]. Each condition uses the key=value syntax, and can be preceded by the type of primitive followed by a / (slash). The set is closed by a ; (semi-colon).
• The new value to be created, optionally followed by a comma and meta-information

(keyword)  'def' +  ':'
[
 condition [ (osm_primitive) 'node'|'way'|'relation' + '/' ] (tag_key)  'key' +  '=' +  'value' + 
 [ '&'
  + condition [ (osm_primitive) 'node'|'way'|'relation' + '/' ] (tag_key) 'key' + '=' + value' + ';' +
  ] 
 + ';' +
]
(tag_key) 'new_key'
[ ',' metadata 'meta']

For example : def:highway=motorway;maxspeed.

• def indicates that we are creating a default value.
• : indicates we are starting the definition.
• highway=motorway indicates that the default value would apply to the objects having the key highway set to the value motorway.
• ; indicates we have given the conditions. This is required if there is a condition.
• maxspeed is the tag of the new default value. All available tags can be used.

Note that, at first, you may be confused by:

• The absence of a condition - a default value can be set for being used in other tags, like opening_hours:holidays, urban.
• The presence of "=" inside the keys. It separates, in the condition, the key to be tested and the value expected. In the examples above, the equal between the default key and its value is surrounded by spaces, while the equals within the key is not.
• By several ':' (colons) in the key:
  • Some conditions can refer to keys that contain this character (e.g. maxspeed:hgv).
  • The new definition may need this character, like psv:maxspeed

Key	Value	Discussion
type	defaults
name	a name for those defaults	optional
description	a description of this set	optional but welcome
def:[(condition) <key=value>;] new_key [, meta]	value

Members

Way or Node	Role	Occurrence	Discussion
	apply_to	at least one	Polygons in which those defaults apply as default values

Questions to be resolved

Syntax

Such a string is allowed in XML files. Is it allowed in the osm DTD ^[2]

How can we define a default value for an object that is within an area (urban)? def:highway=residential[landuse=residential]:maxspeed?

How can we reuse the syntax of the XAPI?

Loops

A relation:boundary can include a relation:defaults as member with the role defaults. The relation:defaults can have the relation:boundary with the role apply_to as member.

The information is redundant. If the editors don't manage well the relation:defaults, the information may be asymmetric.

For engines that do not manage well the relations of relations, the risk is an infinite loop.

Collision

The risk is that an object has several defaults members with the same definition, but with different values. Which would be applied?

They are two replies to your question : if you talk about putting two times the same members in the relation, it's a global risk that we have in all relation objects. Just watch them and fix. If you talk about the same node or way that is surrounded by different default values embedded in different polygons, it's a bit more complicated. Defaults shall apply to an element defining an area, most probably a boundary relation, with a hierarchy. The defaults defined for the smallest area are superseding the defaults of the bigger area. What we need is a kind of 'defaults' consistency checker application verifying that two overlapping areas with the same importance (for instance, two boundaries admin_level 4) are not defining different values. This would be a show stopper for software applications looking for such defaults. -- Pieren 12:55, 30 May 2010 (UTC)

First, I hope that two level 4 boundaries will not overlap, and that shouldn't be a problem any more. I think that Pieren has it almost right with "The defaults defined for the smallest area are superseding the defaults of the bigger area", but I would change it to "the defaults defined by the contained area are superseding defaults of the containing area". (and no, both proposition are not equivalent, mine imply Pieren's, but the opposite is not true )

Question remains : is it technically "very" easy, and if yes, how much easy sletuffe 13:02, 30 May 2010 (UTC)

Examples

• A defaults relation for routing in a country could have these tags  934933 (XML, check, manage, JOSM, history, view, gpx ):
  • type = defaults
  • description = French highway default values according to the Code de la Route
  • def:urban,unit=kmh = 50
  • def:rural,unit=kmh = 90
  • def:highway=motorway;maxspeed = 130
  • def:highway=motorway;maxspeed:rain = 110
  • def:highway=trunk;maxspeed = 110
  • def:highway=primary|highway=secondary;maxspeed = rural
  • def:highway=residential;maxspeed = urban
  • def:junction=roundabout;oneway = yes
  • ...

with one apply_to member : the relation:boundary France  11980 (XML, check, manage, JOSM, history, view, gpx )

• For Norway, where access is allowed for foot even in private ways^[3], defaults could have :
  • def:highway=path&^[2]access=no;motorcar = private
  • def:highway=path&access=no;foot = yes
  • def:highway=path&access=no;bicycle = yes
  • def:highway=path&access=no;foot = yes

• A defaults relation for school holidays could be like :
  • type = defaults
  • description = holidays for French schools of academies of ...
  • name = Vacances scolaires, Zone A
  • def:opening_hours:SH:url,mime=text/calendar = http://media.education.gouv.fr/ics/Calendrier_Scolaire_Zone_A.ics ^[4]
  • def:opening_hours:SH:url,mime=application/json = http://example.com/zone_a/holidays.js ^[4]
  • def:opening_hours:SH = 2010 Jul 3 - 2010 Sep 8,2010 Dec 22-2011 Jan 4

with several subscribers as apply_to members

List of existing defaults relations

France

• France, Code de la Route:  934933 (XML, check, manage, JOSM, history, view, gpx )
• France School holidays Zone A :  957702 (XML, check, manage, JOSM, history, view, gpx )
• France Public holidays :  957715 (XML, check, manage, JOSM, history, view, gpx )

Notes & Links

1. ↑ When several conditions are given, the default value applies to elements that match all of them. The | is not used. It seems simpler to create another rule than writing complex definitions.
2. ↑ ^{2.0 2.1} Must the & be stored as & or & in the database?
3. ↑ See [1]
4. ↑ ^{4.0 4.1} SH is the keyword taken in the opening hours for the school holidays.