Proposal talk:Defaults

From OpenStreetMap Wiki
Jump to navigation Jump to search

Reviving the Proposition

I revived this proposition because everybody speaks of defaults without defining them in the OSM database and because a few defaults exist like driving_side and because a few people do want to define particular defaults but all that without using a common mechanism.
Defining a common defaults mechanism would allow us, for example, to simply add maxheight=4 as default in the right places rather that starting long discussions in each case about there being a default and where to find it.
I found no way to assign it a "reopened" status and it would be appreciated that someone mastering propositions and votes took control of this one.
I have added an important suggestion under #Non-geo-located relations --Papou (talk) 23:34, 25 September 2018 (UTC)

I see a couple of problems with this proposal:
1) The main tag "def" is ambiguous. It's usually an abbreviation for "define" or "definition" in English, or a colloquial term for "excellent / cool" (eg Mos Def, Def Jam). It also can be an abbreviation for several terms, eg. "Design Exchange Format", "Diesel Exhast Fluid," etc., and it's used as a key term in the Python programming language, short for "define".
Instead, I'd recommend using "default:" as the top-level key. This is unambiguous, as far as possible, and it's only 4 characters longer.
2) The syntax is very unusual. Normally all tags are in the format key=value. So the equal size "=" should only be used once. Fortunately, because database users and applications are already accustomed to interpreting "key=value" as two separate strings, it isn't necessary to include the "=" sign in this tag. So instead of "def:highway=service;maxspeed = 50", we can use "default:maxspeed:highway:service=50"; the database user will interpret highway:service as key "highway", value "service".
3) This proposal will have a much better chance of being approved if it is limited to one thing at a time. Rather than trying to make a format for all possible default values, how about just focusing on maxspeed, or another single characteristic? For example, I currently have a proposal to define default language formats, eg the language normally used for names in a region This is already a pretty complicated subject, even when limited to one new tag.
I think you have a good idea, and I hope it can be simplified and win approval. Don't be discouraged by criticism, keep going. I hope you will continue working on your proposal! It's an especially useful idea for maxspeed.--Jeisenbe (talk) 23:55, 27 September 2018 (UTC)

Syntax

The idea is good, the syntaxe is monstruously horrible, but I guess we have no choice given the data container available (key=value).

A few points trying to clear (a bit the syntaxe) :

  • the unit can be used as it allready is, nothing is SI unit this sentence was unclear, I meant : if no unit is given, the SI unit is supposed. But that is not good since SI for speed is meters per seconds, so I correct my thought to, the default unit is the one default for the tag described, and just add def:highway=motorway;maxspeed = 130 mph.

That saves us the def:urban,unit=kmh = 50 syntaxe.

By the way, is it really needed to create such indirections ? I guess the def:urban, is to save repeating 50 a few times, but doesn't that makes it even worse compared to just writing :

  • def:highway=residential;maxspeed = 50
  • def:highway=unclassified;maxspeed = 50
  • def:highway=service;maxspeed = 50

or am I missing something. Could you explain what you meant by urban ? sletuffe 14:59, 28 May 2010 (UTC)

I think the unit could be defined as a default as well. I don't if unit of measures have a standard naming (iso or whatever) but I could see something like : def:unit_of_measures=miles;gallon (or US). --Pieren 19:36, 28 May 2010 (UTC)
- That saves us the def:urban,unit=kmh = 50 syntaxe.
Of course ! It is given as an example of what is possible not as a model of what must be done !
- Could you explain what you mean by urban ?
Proposed_features/trafficzone#Implied_Keys_and_Values, Maxspeed#France,
--FrViPofm 21:24, 28 May 2010 (UTC)

Non-geo-located relations

So this relation will not have any nodes or ways in it? It's not geo-located in any way. Just relation dangling nowhere in space? -- Harry Wood 12:03, 29 May 2010 (UTC)

Indeed the type=defaults relation has no location, it's just a bucket for tags. These tags apply as defaults to elements inside one or several geo-located relations. Note that applying to several relations can reduce redundancy.
No indeed one cannot find a defaults relation by itself with overpass turbo because it has no bbox to search in nor to show them in: one must "go through" a geo-located relation first and follow its pointer found in an element with role "defaults".
There may be something I don't understand, but the answer to the [proposed Overpass query]. is empty.
So, I suggest that the default tags could be either:
  1. in one or several "defaults" relations pointed to by an element with role "defaults" each. "several" allows reusing the same non-duplicated defaults (e.g. European) for different relations (e.g. European countries) together with other defaults (e.g. national)
  2. or directly in a geo-located relation as zzdef:*=* zz is used to unobtrusively put the zzdef tags last
  3. scan order to get a complete tag list is role "defaults" elements in their relation order followed by "direct (zzdef)" so that first elements (e.g. European) are overridden by subsequent ones (e.g. local country) and finally by zzdef. Or the scan for a single key is in reverse order and stops as soon as the key is found. Papou (talk) 18:48, 24 September 2018 (UTC)

If I understand it correctly, yes. There is no way to have access to it by bbox query methods but using the API with the "/relations" parameter on a given relation. sletuffe 09:25, 30 May 2010 (UTC)
- They are other relations that are not necesarily geo-located site (may include multipoligons), boundary (may have only boundary_segment)... Is it technicaly a problem ? --FrViPofm 22:13, 6 June 2010 (UTC)
So what is the suggested way of getting this relation, given a location and a very complex country-multipolygon that contains this location? --MarcusWolschon 15:08, 12 June 2010 (UTC)
- I think the relation must be included in the boundary relation with the role default. The risk, for not up to date tools, is entering in an infinite loop. But for tools working on an area, they can find the osm_id of the defaults for each boundaries included, natural parks, cities... An other suggestion ?--FrViPofm 07:42, 13 June 2010 (UTC)
I think the role name should be 'defaults', not 'default' as the relation provides all default values. -- Pieren 08:01, 5 July 2010 (UTC)
OK. --FrViPofm 08:37, 6 July 2010 (UTC)

rule-language

I think the proposed, defined rule-languages is not complete enough. e.g. the maxspeed for a highway=primary is usually different inside and outside closed cities. We have country-wide maxspeeds that depend e.g. on the type of vehicle. So if it cannot descript all speed-limits in any country completely, then it failes in it´s primary purpose. --MarcusWolschon 15:06, 12 June 2010 (UTC)

What about such a set :
Maybe someone could suggest an other syntax
--FrViPofm 08:50, 23 June 2010 (UTC)
I do not thing this is a good suggestion. The first line rather means to all highway=primary add tag rural:maxspeed = N. I see three possible solutions to this:

1. If we want to conform to Proposed_features/trafficzone than just use def:highway=primary&zone:traffic=XY:rural;maxspeed = N.

2. If you do not agree with the trafficzone proposal, than we can decide that we want to keep things simple and we just list all cities from the country in the defaults relation.

3. If you do not agree with the trafficzone proposal, and do not care about adding a bit of syntactical complexity, than I would suggest to introduce new tag apply_if_within valid for the whole realation. For example if we want highway default for Czech republic would use these two relations (in Czech republic maxspeed is 90 outside cities and 50 inside cities on primary roads):

first general relation

than relation for urban areas

--Jakubt 23:52, 16 August 2011 (BST)

Holidays

Sub ralation for (school) holidays, which uses only a mime type and reference can not be parsed like for exmaple maxpeed in the main default relation. The idea should be extended and there should be a specialized type=holidays relation which can use mime-references only in addition to a parseable text-format.

Since many holidays are relative x days to easter (and sun/moon states), on a fixed date or the y. weekday of month z. this should be possible wich an extended and better openning_hours-like sheme. --Fabi2 22:07, 21 August 2010 (BST)

API key/Value length restriction

I tried to add a relation for the whole country German public holidays (relation 2188155) in Netzwolf syntax. Even with this few values it hits the API limits so these cases should be handled somehow. --Fabi2 23:43, 17 May 2012 (BST)

Problematic characters in keys

There is an ongoing discussion on Github about the idea of disallowing the use of certain problematic characters in keys.[1] The discussion follows the guideline on Any tags you like#Syntactic conventions for new tags. This proposal for defaults has been named as one source of problematic keys in OSM.

I suggest that defaults are documented on a Wiki page much like Default speed limits instead of in OSM itself to follow the abovementioned guideline and to prevent conflicts with a future API update. --501ghost (talk) 13:51, 22 November 2022 (UTC)

References

  1. ↑ https://github.com/osmlab/osm-data-model/discussions/23
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Defaults&oldid=2513274"