Proposal:Defaults

defaults
Proposal status:	Inactive (inactive)
Proposed by:	FrViPofm
Tagging:	type=defaults
Applies to:	relation
Definition:	Relation for defining default values
Statistics:
Rendered as:	Not rendered
Draft started:	2018-09-20

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.
Note: should be part of the proposition:
type=boundary relations should contain a defaults element role indicating the type=defaults relation applying to them.
When searching to apply a default, the boundary relations should be "scanned upwards" until the most appropriate default is found.
And so, a parent role in the boundary relations is most helpful to do so to point to the upper level one.

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 tags as varied as tunnel maximum height, official languages, speed limits and holiday periods. Instead of finding the default data in the OSM database, routing engines currently need to retrieve it from other sources, which can be difficult to code, and of varying availability, timeliness, and quality. Instead of advising the user to routinely update the OSM map, it requires to upgrade every other GSM in different ways.
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. That way, a contributor can use his usual OSM editor to update defaults more or less like adding tags but to the defaults relation rather than to each object.

This is the aim of the relation type defaults.
This relation can pointed to by members of other relations such as administrative with a role of defaults.
When looking for defaults, administrative relations are scanned from smallest to largest until a matching default is found.

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 &. 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

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 934933:
  • 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 11980

• For Norway, where access is allowed for foot even in private ways, defaults could have :
  • def:highway=path&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
  • def:opening_hours:SH:url,mime=application/json = http://example.com/zone_a/holidays.js
  • 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

For an automatic list with all defaults relations and their tags, you can use an Overpass query.

Below is a manually curated list. If you created or found a new relation, you can add it here.

Algeria

• Public holidays: 6608271 6608271

Belgium

• Federal highway default values: 6900538 6900538
• Flanders-specific highway default values: 6900533 6900533
• Wallonia-specific highway default values: 6900513 6900513

Denmark

• Highway default values: 1124103 1124103

France

• Highway code: 934933 934933
• Scholar holidays:
  • zone A: 957702 957702
  • zone B: 5963035 5963035
  • zone C: 5963036 5963036
• Public holidays: 957715 957715

Cities

• La Frette Sur Seine: maxweight restriction 6118341 6118341

Germany

• Public holidays: 2188155 2188155
• Street code: 8131479 8131479

Italy

• Highway code: 1124248 1124248

Vatican City

• Highway code: 1124240 1124240