Proposal:Admin title
Key:admin_title | |
---|---|
Proposal status: | Rejected (inactive) |
Proposed by: | fkv |
Tagging: | admin_title=* |
Applies to: | |
Definition: | name of the administrative division |
Statistics: |
|
Rendered as: | text preceding the name, or text in parenthesis after the name, or none |
Draft started: | 2014-10-02 |
RFC start: | 2014-12-17 |
Vote start: | 2015-05-10 |
Vote end: | 2015-05-24 |
Rationale
The names of administrative divisions, such as "state", "district", "county", and "borough", do not only depend on country, language, and admin_level=*. They vary even within countries. E.g. a Bezirk is a subdivision of the Gemeinde in Vienna, but a Gemeinde is a subdivision of a Bezirk in other parts of Austria. Therefore, implementing tables and decision trees in applications would be too much of an effort. Given the persistence and limited number of most administrations, it seems more efficient to keep these names in the database, specifically on boundary relations.
In this respect, there have been a number of tagging approaches:
- Completely omitting the division name.
- Adding it to name=*, which results in easy rendering, but complicates other processing of the data.
- Putting it into name:prefix=*. This enables renderers to stuff prefix and name together to make the display name. This works, however, only for division names preceding the feature names, and only if they can be put together without declension. It won't work for e.g. megy + Zala = megy Zala (wrong), correct: Zala megye. Another issue is that name:prefix=* is defined lexically, but database entities should be defined semantically. A prefix can mean anything. Consider personal names, for example. They can be prefixed by "Mister", "Lord", "Sir", "Doctor", "President", "Dear", "Sergent", "Captain", "plumber", etc., or an arbitrary combinaton of these. How can an application make use of a name prefix? It can display it, but it cannot use it in any other way, e.g. for statistics or data mining.
Therefore, I suggest a distinctive new key name.
Tagging
Proposed tagging is analogous to protected areas.
protected area | administrative boundary relation |
---|---|
type=boundary | type=boundary |
boundary=protected_area | boundary=administrative |
protect_class=* | admin_level=* |
protection_title=* | admin_title=* |
name=* | name=* |
Example: 300565837 300565837
(would be type=boundary if it were a relation) boundary=protected_area protect_class=4 protection_title=Naturschutzgebiet name=Meloner Au rendered name e.g. "Naturschutzgebiet Meloner Au" or "Meloner Au (Naturschutzgebiet)" or just "Meloner Au" |
Example: 446158 446158
type=boundary boundary=administrative admin_level=6 admin_title=Bezirk name=Zwettl rendered name e.g. "Bezirk Zwettl" or "Zwettl (Bezirk)" or just "Zwettl" |
alternative keys which came up in the discussion
- designation=* used in the UK, see User:Csmale/ukboundaries
- official_status=* (not documented) used in Russia, see talk page
Discussion
Please leave your comments on the talk page.
Voting
- I approve this proposal. --Fkv (talk) 07:59, 10 May 2015 (UTC)
- I oppose this proposal. I prefer using designation=* for this as suggested on the talk page. Any problem with using designation=* is not insurmountable and can be resolved through discussion and standardization. —seav (talk) 20:50, 10 May 2015 (UTC)
- I oppose this proposal. I don't think this is a mature proposal. It fails to explain how admin_title would solve the declension problem mentioned as a reason against using name:prefix. Also the tag name doesn't sound right; places do not have a "title" at least not in my understanding of English. --Frederik Ramm (talk) 06:58, 11 May 2015 (UTC)
- I oppose this proposal. I think this is often/mostly part of the name and could likely be included/excluded somehow in the various name tag variations (e.g. name=*, official_name=*, short_name=*). "Title" also does not seem to be an appropriate referer for what you want to tag.--Dieterdreist (talk) 09:58, 11 May 2015 (UTC)
- I oppose this proposal. I don't like the name (title?), I don't see any advantages over official_status=*, which is used over 60k times, compared to 1 (one) instance of admin_title, and I think this proposal has not been thought through: e.g. there are no examples, no hierarchy and so on. Sorry. --Zverik (talk) 10:04, 11 May 2015 (UTC)
- I see at least one advantage over "official_status": there is documentation what it is about. There is no documentation on official_status so this key is useless to me, as I don't see what it is about, and the key name is too generic to allow interpretations. --Dieterdreist (talk) 09:03, 12 May 2015 (UTC)
- I oppose this proposal. If you use the tag prefix:name in the planned way, everything would be fine --wambacher 10:18, 12 May 2015 (UTC)
- I oppose this proposal. no advantage over prefix:name; use tags like 'de:regionalschluessel' for analysis Waldhans (talk) 12:56, 12 May 2015 (UTC)
- I oppose this proposal. The "admin titel" is part of of each administrative bodies official name. E.g. if Bielefeld really exists, it would have the official name Stadt Bielefeld, see Hauptsatzung, § 1 (Please note that the bielefeld.de Server is located in Düsseldorf, so the existence of that town still remains mysterious).
The proposal was rejected with 7:1 votes. Judging from the comments, there is no desire for a unified tag. --Fkv (talk) 10:46, 26 May 2015 (UTC)