Talk:Relations/Proposed/add admin centre in Relation:boundary

I don't think this should deprecate any capital=*, though I find this to be a useful tag, specially where administrative center have a different name than the area (as in municipals where the town have a different name, examples Batnfjordsøra is the administrative center of Gjemnes in Norway). I still think there are use for the capital tag. I guess renderer can take informations from relations as well as the tagging, but what about all the state capitals where there are no mapped border yet? Many places still struggle with copyrighted information about border lines. And to remove the capital tag will make them rendered only as plane cities. --Skippern 18:21, 2 December 2008 (UTC)

As said, if the relation does not exist, we keep the admin_level on the node. The tag capital=* is a bit a duplicate of admin_level=*. But I know that deprecating tags is always controversal. So I will remove the deprecation if I see more complains about that. Copyrighted sources is not an issue for national borders imho but rather for smaller admin entities. -- Pieren 18:31, 2 December 2008 (UTC)

I have tagged the state capital of my state with capital=yes and admin_level=4 to indicate that it is a state capital, to add it as a member of the state border relation will only improve it, but up until I had made the relation for the border, the tags where essential to show that it was a state capital. I see no point in a relation removing the need for that tag. --Skippern 18:36, 2 December 2008 (UTC)

Do you mean that you tag other nodes with admin_level=4 which are not the state capital ? If yes, ok you are right. Otherwise, it's duplicate. And how do you manage the place which is the capital of the state and the capital of the country ? -- Pieren 18:59, 2 December 2008 (UTC)

At the moment only 2/3? states out of 26 states have a border entered in OSM, besides I tagged the state capital when I still not had enough data to draw the state border. For a city with multiple functions I would tag with the highest (state capital and national capital would be admin_level 2) --Skippern 20:17, 2 December 2008 (UTC)

Name of Role

This Feature is very good idea, I was already thinking about making a proposal myself. At the moment it's rather hard to find the place, the boundary belongs to. The only concern I have is about the name of the role. Now it's 'centre' which could raise concern what kind of centre it should be (geographic, administrative, ...). Maybe 'place' could be a better name, because it's also the tag which is used to identifies the central node. But I won't vote against the name 'centre', if the majority favours this name. -- Skunk 08:46, 12 December 2008 (UTC)

But what is it actually we are going to use as the 'centre'? Is it the border relation of the nations capital, or the place tag, or the parliament? What about states, districts, towns and municipals? I feel this proposal lack a definition of what it should point at. --Skippern 09:30, 12 December 2008 (UTC)

I'm looking for a better name than "center". I agree that it is not clear and I would appreciate if someone gives a better definition. The node represents the administrative boundary. For admin_level=2, a country, it will be the node representing the country capital. For admin_level=8, it's the node representing the town/city/village. Perhaps name=* is better than "center" or "admin_center" or "admin_place". Pieren 10:36, 12 December 2008 (UTC)

I would call it label=*", cause that's what it is. The position, where the name label is placed. --Lulu-Ann 11:22, 12 December 2008 (UTC)

Well, it's not only a label. The place node carries other information like population, post_code, etc. Of course, the node is also used to position the label on the maps. That's why my preference goes to "place" at the moment. -- Pieren 11:28, 12 December 2008 (UTC)

For my home town I would say it is important to know if it is to be put on the town that is the municipal center, the town hall, or some other place of importance, since this is very different location. The town hall is not in the center of the town, but on the outskirts, the place=* is put on a highly populated area, but far from the center, and the centro (downtown) suburb doesn't have a single administrative building. --Skippern 11:35, 12 December 2008 (UTC)

For me this relation doesn't point to the Country Capital (as an example), but actually the place where the name is being rendered. E.g. Every city/state/country is identified by a node (e.g. 21015489 21015489, 26847709 26847709). Many of this cities/states/countries have boundaries (as relation, e.g. 34719 34719, 16239 16239). So I would also find the role 'label' acceptable, but would still prefer 'place'. -- Skunk 14:23, 12 December 2008 (UTC)

So basically you want a state border relation to also point at the place=state tag, a country border relation to place=country, a municipal border relation point to place=* with the name of the area in question. If this is the purpose of the tag, than it doesn't in any way replace or duplicate the capital=* which have been argumented somewhere else in the discussion. --Skippern 14:36, 12 December 2008 (UTC)

Yes. -- Skunk 15:21, 12 December 2008 (UTC)

I forgot that a node may represent the country. I think that we have to keep the relation as simple as possible. Only one node should be linked. This node represents the administrative entity. At admin_level 2, it can be the capital itself or a specific node tagged place=country. The role 'place' is still my preference btw. --Pieren 15:30, 12 December 2008 (UTC)

What about label=* for where you might want to put the label, and admin=* for where the administration center is (houses of parliament/town hall), and capital=* for links to the capital of a state or a country? If a border relation is set on the capital, why not inherit that as capital=*? --Skippern 15:33, 12 December 2008 (UTC)

I think that the label=* is a more general problem. It's also useful for all multipolygons (e. g. lakes and forests) to define the place of label. Mostly if the shape of object is concave, because in this case the default place of label is outside of the object. --City-busz 08:55, 30 January 2009 (UTC)

I think some entities have different capitals : politic, administrative... For example European Community, with Bruxelles, Strasbourg, Luxembourg... (witch admin_level ?) and some countries... We have to keep the relation as simple as possible, yes but also meaningfull. The metadata (population...) can be attached, by default, to the node place, or to a node label when a node center or center:admin, center:politic' is used...FrViPofm 16:47, 6 April 2009 (UTC)

Second draft comments

here

As mentionned above, I am more in favor of creating a new tag label=* for a specific renderer placement of the label applied to a node that has no other properties than showing it's a renderer specific thing (not a physical thing). Also would be usable with any kind of surface thing. (The label role can be preserved in the relation as well). For the admin_center role, I'm okay with it. Sletuffe 16:41, 7 April 2009 (UTC)

I try to limit my proposal to the relation boundary. What you suggest - if I understand correctly - is to replace the node "place" by a node "label". But this might raise other issues (like multiple villages inside a boundary) and should be part of another separated proposal/discussion. -- Pieren 17:33, 7 April 2009 (UTC)

We can create it in the goal to serve admin boundaries but without preventing other uses. To make it clearer, I suggested to replace the node "place" by a new node with key "label" ONLY in the label role, not in the admin_center role. The use of place=country/region/county/state on a node is something I find completly strange.

It seems to be a well established practice now. Pieren 13:47, 8 April 2009 (UTC)

I don't get you, what is the link between the label and multiple villages inside a boundary ?

I see that your suggestion is only about the label which is for high admin levels. But for low admin levels, let say for instance an admin_leve=8 boundary (municipality) with two nodes place=village. The municipality is maybe taking the name of one of the village or both of them. Then the controvery starts about which place node you are replacing or not and so on... -- Pieren 13:47, 8 April 2009 (UTC)

Also I agree label=* should be started in a separted proposal, but it's main use would be for this proposal, so close connected to it. Sletuffe 11:23, 8 April 2009 (UTC)

The use of place=* on a node is the the most common thing. In the Europe-export there are more than 300.000 nodes, tagged with place=* (e.g. 54 countries, 38 states, 350 regions, 957 cities, 14190 towns, nearly 200.000 villages). On the other hand only 8500 polygons (e.g. 0 countries, 1 region, 373 cities, 237 towns, 2620 villages). -- Skunk 13:14, 8 April 2009 (UTC)

Don't reinvent yet another label relation. Keep admin_center (or whatever you want to call it), which is actually useful data, and if somebody want to hint to the renderer they can use a separate label relation. Bobkare 18:01, 8 April 2009 (UTC)

It's not because a relation proposal exists for labels that all other relation proposals should exclude labels and force people to create two relations when one would be enough. I fully agree about one OSM motto "We need the simplest quickest way of entering the data". -- Pieren 20:30, 8 April 2009 (UTC)

For me the essential thing is the "label"-role, because now you can tell a place-node which boundary it has. I'm already using it in my application, now I had to guess on whether there's node with the same name, which is inside the boundary and has a suiting admin_level (e.g. [1]). On the other hand most of the boundary-relations have been changed to multipolygon-relations ... -- Skunk 03:46, 9 April 2009 (UTC)

I want to note that a relation may serve as many purposes and match as many feature-proposals as the users want to. There need not be 2 relations for anything if the roles and tags do not interfere. Thus if another proposal has a role for a label-node, we should use that so that it is possible for both to be mapped in one actual relation if the mapper thinks they overlap enough to warant that. Additional members with roles not covered here are ignored for the semantics of this proposal as with any relation. (PS: it's a shame boundary and multipolygon are mutually exclusive due to conflicting use of the type-tag) --MarcusWolschon 05:44, 9 April 2009 (UTC)

When I read "admin_centre" I am still confused whether this is supposed to represent a capital city or a government building. I would like to propose renaming admin_centre to capital. (See Relations/Proposed/Country.) Advantages: The name of the role is shorter; there's no misspellings due to American English (center) vs. British English (centre); and it's less ambiguous -- less likely to be confused with a government building or rendering hint. --Elyk 01:43, 4 July 2009 (UTC)

If we want to add the government building to the relation (I'm not sure if this is the place for it though), we could add the building with role=capitol. If you're confused between capital and capitol, consult a dictionary. --Elyk 01:43, 4 July 2009 (UTC)

What do we add to the capital role, the capital's boundary relation or a place node? A place node is useless when you have a boundary relation that can contain all of the same information. I would only use a place node if the boundary relation doesn't yet exist. --Elyk 01:43, 4 July 2009 (UTC)

parent/child

I am all for this. If you have the node of a city you at least get an optional hit as to the Id of it`s bounding-polygon. Saves lots of expensive range-queries. If we add the capital to a country, why not have 2 more optional roles: "parent" and "child". If someone wants to tag it he/she can tag the states to be children of the country, the cities to be children of the state, ... (I did not forbid having multiple parents. Germany is in Europe as a continent but also in the EU as an administrative area). This could make many guesswork we currently have to do much easier. --MarcusWolschon 16:58, 7 April 2009 (UTC)

I think we can do even better :-)

First I should say I like very much how this proposal solves some problems connected with Proposed_features/capital. However I think that we can do better and replace the boundary altogether, since there are several problems wiht is. It is used for connected boundaries as well as for boundary segments. Also the terminology sounds somehow strange - "boundary has a administrative center". The center is not connected to coundary but to region, or area ... And third thing to mention is that for and area, or region of however you call it there can be several "centres", not only administrative one. I am trying to implement all this into proposal Relations/Proposed/Region and this proposal was a big inspiration for me. I would be happy if you have a look at it and help to rafine it. Thank you --Jakubt 22:33, 28 August 2009 (UTC)

Bad idea to tag the label node with place=*

I like the role=label idea a lot, and many people are already implementing it on various admin levels even though Mapnik does not honor it and osmarender, I am told, does only an okay job at it. However, I think it's a very bad idea to tag the label node with the same place/admin data as the relation. The reason being it screws up Nominatim child/parent data in a big way. Just take a look at "Los Angeles, Ventura (county)" (should be Los Angeles, Los Angeles (county); it gets incorrectly parented by the Ventura county node, which someone placed too close to the county border, even though there is a perfectly good Los Angeles county polygon that the city of LA should and would have been parented by - if the Ventura county node did not exist. Every OSM expert recommends deleting place nodes (such as Ventura county node) once the place polygon or boundary relation is available. Unfortunately, if I were to do this today, the label for Ventura county would disappear from the rendered maps even if I were to create a Ventura county relation with a label node. Why? Because, as I mentioned, neither Mapnik nor Open MapQuest honor it. They have to be taught to, and the way it should work is this: render the place/admin label at the location of the role=label node using the style and zoom behavior of the place/admin found on the boundary relation. The label node should only have to be tagged with name=*.--Ponzu 00:11, 14 April 2011 (BST)

I support the role=label idea. But I think that the node should not have any tags. The name-tag should be in/on the relation and the node only supply the position. This will make it easier to edit where all tags are in the relation and not in two places (name on node and "feature-type" in relation).--Thod 23:50, 4 November 2011 (UTC)