Proposal:Region
_-_The_Noun_Project.svg){kind=small}
| Relation:region | |
|---|---|
| Proposal status: | Abandoned (inactive) |
| Proposed by: | gorn |
| Tagging: | type=region |
| Applies to: | relation |
| Definition: | Relation for representing hierarchies on the map of any kind (geographical areas, religional districts, administrative territories, zip codes, ...). |
| Statistics: |
|
| Rendered as: | hidden, or with emphasized border and center if appropriate. |
| Draft started: | 2009-08-26 |
| RFC start: | 2008-12-19 |
| Vote start: | * |
| Vote end: | * |
This proposal introduces simple but powerful way to represent many paralel hierarchies on the map. It reaches this goal by defining very simple and general notion of region. It emables us to show all kinds of relations like districts forming a city, counties forming a state, of peaks belonging to mountains etc. See more examples below.
Rationale
There are many cases when points, ways of areas belong to some bigger area, which forms some kind of geographical of administrative hierarchy (state, county, city, ocean, zip code zone, religion district etc). This proposal gives powerful structure which is general enough to be used in many of these cases, yet specific enough to solve real life problems. By using Relation:region we represent many parallel hierarchies on the map.
These are the main arguments for the proposal:
- It gives hierarchy of places and areas
- It gives is_in information for free
- It handles parallel hieararchies
- It allows different national schemes work nicely together
- It handles all kinds of capitals well
Before we go further into details of proposal and show it indivudual strong points, I think it is good to show little bit about of history of representing hierarchies on the map.
Historical attempts to represent hierarchies on the map
Some time ago the need to enter such relations transformed to is_in=*. The usage of simple is_in did not suffice, so there were all kinds of more accurate is_in's added like is_in:state, is_in:country etc (see is_in=*).
At 2007 the relation Is In to handle better this abstract concept was proposed.
To some extent similar issues have been discussed in Talk:Relation:boundary partially due to a vague definition of Relation:boundary which tried to deal with "areas" (in case of closed boundary) as well as "boundary-segments". This (probably unintentional) confusion transformed to proposal of boundary_segment relation which tries to clarify things as well as to proposals like this one which in case of non closed boundaries have no meaning, but are inspirational in case of closed boundaries.
My proposal of region relation can thus be viewed as continuation of several proposals mentioned here. See also related tags and relations.
rationale for the proposal
Relation Tags
| Key | Value | Discussion | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| type | region | |||||||||||||||||||||||||
| name | * | name of the region | ||||||||||||||||||||||||
| region_category[1] | administrative / legal / cadastral / telephone / postal / political / maritime / topological / time_zone / religious | |||||||||||||||||||||||||
| region_type |
|
Specifies region type within the scope of defined region_category. For different region_categories there is different set of values. More here ... |
Relation Members
| Way or Node | Role | Recurrence? | Discussion |
|---|---|---|---|
 [7], 
|
boundary | one, this member is required | either simple closed path or Advanced multipolygon system to define more complex boundaries. |
 ,
|
center (or capital)[8] | one, this member is optional | What is the capital or center of this region. It can be anything from capital of the country to district town, or seat of Bishop in Diocese, depending on the region_type and region_category. |
|
|
subregion | any number of, optional | this would refer to other relation's region, which are subregions of this region having the same region_category.[9] |
Details, features and advantages of proposal
It gives hierarchy of places and areas
The proposal consistently gives hierarchy of places and areas. To some extent it can replace most information encoded by is_in's without any additionlal effort.
Let's talk for a while about Relations:region marked with region_category=administrative for a while.
For example we can have a look at "Château de Bagatelle" in Paris and find out what is the smallest region in which it is contained. This is area with has these values set
region_category=administrative region_type=arrondissement name= XVIe arrondissement
So we see that Château de Bagatelle is in "XVIe arrondissement". If we repeat this procedure with "XVIe arrondissement" we find next area with
region_category=administrative region_type=department name=Paris
We reapeat this as far as we want and is terms of ancient is_in we see, that:
Château de Bagatelle is_in=XVIe arrondissement,Paris,Île-de-France,France,European Union
And we do not have only this information, wee know at each level what kind of entity we are looking at, so we may skip region names for example, of to stop at the country level. We also see that XVIe arrondissement is 5 levels deep in the (administrative) structure, so we can easily decide which colour and thickness we will render its boundary etc.
It gives is_in information for free
There are many disadvantages of is_in=*. With this proposal 99% od is_in information can be automatically generated.
The Key:is_in has two main disadvantages.
- It repeats same information on mutiple places (which is one of worst sins in data handling).
- If does not use information which are already on the map.
The is_in information for many places repeats the whole sequence of hierarchy. (i.e. is_in = 16 arrondisement,Paris,Ile de France,France for a building and then is_in=Ile de France,France for Paris etc.) This disadvantage was well recognized in Talk:Relations/Proposed/Is_In where the partial solution is in replacing is_in by relation. In the discussion many benefits of recursivity of "is_in" or "belongs to" relation was recognized and proposed to be implicitly present or at least automatically added (as is_in_inherited tag). To simplify we are able to use is_in:arrondisement=16th arrondisement of Paris for a building only, and all other tags like is_in_inherited:city=Paris and is_in_inherited:country=France can be generated automatically.
But there is the second disadvantage! That is that we still need to mention the first fact and that is that the building is 16th arrondisement of Paris. But why, when it is obvious for from the map itself! If can recognize regions which are important for administrative purposes, than we are able to find the smallest one in which the particular building is located. So there is no need to add this information by hand and it can be either generated automatically, or even computed in real-time.
We have cut duplication of information to zero.
It handles parallel hieararchies
There are many overlapping hierarchies on the map and they are ofter quite independent. Relation:region can handle well any number of parallel hierarchies..
Map is naturally divided in hierarchical structures of areas which belong to each other. Relation:region models this very well and allows to handle more parralles hierarchies. Each hierarchy has it's own region_category value, so we can easily switch them selectively on and off. Religious borders does not respect geographical or administrative ones.
By looking on all parents in all hierarchies, you can also provide very comprehensive information for user. Thus by starting in Jilemnice in Czech republic, we are able to find out it place in administrative hierarchy (regoin_caregory=administrative): it is in district Semily, county Liberec, country Czech republic. Looking at hierarchy marked region_class=religional we find: vicariate Jilemnice, diocese Hradec Kálové, etc...
Another crazy example might be to look on the Château de Bagatelle. You will see, that geographically it belongs to "Bois de Boulogne" which in turn administratively belongs to Paris and this is in the CET = UTC+1 time zone. Any combinations is possible.
It handles all kinds of capitals well
Be it Capitals, bishopries, district towns, it nicely encaptulates all of this to one general concept.
Many regions has its center, which have different meanings depending on region_type and region_class. This proposal give nice possibility to generally mark this relation, giving renderers way to use this information without need of implementing separatedly all disjoint notions of "center". And this generalization is done without loosing necessarry details!
There is a Proposed_features/capital proposal, which however lacks this connection to region and information about region_type which leads to some problems. Here are some examples of difficult cases which our proposal handles well:
- A city can be a capital of a larger administrative unit without also being a capital of the smaller unit it's located in. To give two examples: Ottawa is the capital of Canada but not the capital of the province of Ontario, in which it's located. So simply marking Ottawa as capital is not sufficient. However if we have two relations: <Ottawa> <is center of region> <Canada> and <Toronto> <is center of region> <provice of Ontario> than enerything is clear enough. [10]
- If we are looking for the "authority town" for a small city, we can use Relation:region to find out which one is it and we may be given several different answers. For example if we are in city Jilemnice in Czech republic, than administrative authority can be found in Semily which is district town for Jilemnice. We can go one step higher to Liberec which is county seat, of to Prague which is capital of state. This was however purely administrative point of view (we have used sequence of containin regions with region_class=administrative). However is we are looking for religional authority, we will use relations classed as region_class=religional and we will get totally different result: in first step we find Jilemnice itself is center of Vicarate it belongs to. Than we find Hradec Kálové as bishoprie of diocese, and finally Vatican City.
There is also Relations/Proposed/add_admin_centre_in_Relation:boundary which i like, but which is covered by this proposal as well.
It allows different national schemes work nicely together
Names of levels in hierarchies can be hard to agree on if not impossible due to national differences. Our apploach does not need anything like admin_level=* in boundary=*.
However, there is a very big advantage with our approach and no unnecessary standardization is in fact needed.
Take region_category=administrative as an example. Some countries have provincies at the first level of hierarchy, some of them on second level. To be able to render the hierarchy consistently there are things like Key:boundary#10_admin_level_values_for_specific_countries necessary at the moment. This is very practical indeed but also very artificial. Oour approach is much more cleaner in this. Renderers can simply derive the deepness of the region in hierarchy and use this for the rendering (for rendering the border for example, or giving possibility to select areas by mouse clicking).
No hard coded hierarchy numbered levels like admin_level=* are needed anymore. If you need you can introduce additional level of hierarchy without redefining anything and it will be rendered correctly instantly.
I have just noted that taken to extreem, we can decide to leave region_type values empty in some cases. Nice use case is type_category= valley. Surely there are cases, when local valleys are parts of some bigger valley. In thi case there is no need to come up with something like super_valley / valley stucture. We can just use region_type=valley for all of them, or just leave region_type emty at all and use subregion=* for the hiararchy of valleys.
Notes and appendices
Note about finding inside and outside of region
For discussion about how to find out what is inside and outside of the region see Relation:multipolygon.
Note about the proposed relation name
I am not 100% sure that there is no better english world that region for this concept. I thought about things like territory, set, area, group, but the region sounded best to me. If you disagree, please let me know on the talk page.
Note about Relation:is_in
On the abstract level, the Relation:is_in which is not connected to any geographical facts is very clean and nice proposal and I like it very much. My intent is not to replace it, it very well exist together. On the other hand, we are building a map, not a semantic wikipedia (like http://www.freebase.com/, which BTW can help with our effort). Therefore majority of our is_in relations can be derived from simple inclusion principle. And that is exactly where my proposal comes.
Related tags and relations
Ideas in many tags and relations which are both in use or proposed can be inspirational for this proposal. We should reuse what worked and learn from problems in these related concepts. Therefore it is good to have list of them:
- amenity=place_of_worship - region_category=religion can inspire the way different religions are handled and use same value set as religion=* and denomination=* which are used in conjunction with amenity=place_of_worship. Thanks User:Skippern for pointing this out.
- Relations/Proposed/add_admin_centre_in_Relation:boundary - ideas about tag center.
- is_in=*
- Relation:multipolygon
- Relations/Proposed/Is_In
- Proposed_features/capital - here we should learn from problems uncovered in discussion.
- Proposed features/Massif
- Proposed features/Valley
- .... please add more.
Discussion
This is for discussion of udecided parts of proposal, its weak points and your ideas.
Please, please if you have any examples, ideas etc. let me know here or on the talk page.
Naming convention: Center, centre or capital?
How the proposed membership relation should be called?
It is British vs Americal English issue. How this is usually solved? Capital sounds also good but it is not general enought. What is your opinion?
References
- ↑ this key may be named also simply region or region_class; just "region" would be more along the lines of type=route, route=hiking
- ↑ areas for which a legal court has jurisdiction see [1])
- ↑ telephone zone, depending on numbering plan)
- ↑ what would be the best name here?
- ↑ should probably be merged either to administrative. We should check out what kind of maritime boundaries are defined and to which of these systems if belongs better.
- ↑ for ideas about handling different religions, see Related tags and relations
- ↑ we may also decide that we require multipolygon here by default, or on the other hand we may allow Relation:boundary to be referenced as well
- ↑ please let me know what you thing is the best naming convention here
- ↑ There is a little contravesory about this. This information can be easily derived from looking for all regions of the same region_category which are not included in something which is itseld subregion. However for efficiency reasons, this would be probably too difficult to look up anytime the renderer (or anyone else) needs the information. However this information can be automatically generated by a computer bot.
- ↑ Likewise, Lansing is the capital of the state of Michigan but not the seat of Ingham County, in which it's located.