Talk:Relation:boundary

Coastlines

Should coastlines be added to this relation as well ? --Skywave 22:04, 27 March 2008 (UTC)

If you meant, "should the coastline portions of administrative boundaries be included in the relation?", then I would say that they should. --Hawke 22:47, 27 March 2008 (UTC)

Yes, i meant that. --Skywave 07:03, 28 March 2008 (UTC)

If the coastline is the border, then of course it should be added. But the coastline seldom is the border. See e.g. Zeeland [1]. IIRC there was a discussion about borders at sea on the "talk" mailinglist last January or February. --Cartinus 22:02, 8 April 2008 (BST)

I think the coastlines should not be part of this relation, for a couple of reasons. First, the coastline is not the official border of a country. The border is almost always at the 12-nautical-mile-zone. Then, consider an island nearby the coast of the mainland. A ferry line to such an island would usually take place inside a country, e.g. there are no border checkpoints on such a ferry. But with the coastline as border this ferry would become international. Furthermore, there are about 70 times more coastline nodes than border nodes. So taking the 12-nm-zone would significantly and fruitfully reduce the data amount. -- User:Roland.olbricht 13h06, 4 November 2008

See Maritime_borders for "old" proposals and definitions on borders on the sea.

This is absolutely a valid point to discuss, as I am trying to draw a border around a state, where coastlines make up about half of the border, there are as well two islands belonging to the state, but further than 24nm from land. I guess the islands can be added as some sort of enclave or exclave (I am not sure of the right term) later. The problem I have now is that uploading the relation with only the border to the neighboring states gives an error. So what is then right, to draw an artificial line off the coast, make the coastline part of the relation, or what else? There are a few islands along the coast as well, using the coastline as border will mean I have to include all the islands in some way or another. --Skippern 20:22, 30 November 2008 (UTC)

A related question, what should be done with the exclusive economic zone (EEZ) [2]? --Eimai 21:07, 30 November 2008 (UTC)

See my comment on Talk:Maritime_borders --Skippern 21:13, 30 November 2008 (UTC)

The coastline should absolutely not be a part of this relation. The baseline or territorial waters should be used. -- Gustavf 15:32, 9 March 2009 (UTC)

Enclave/Exclave

A better explanation of the enclave/exclave usage would be appreciated. Taking the first example from the wikipedia enclave link, would A's border be marked as outer, and C's as inner? Would it be able to handle multiple outer ways, as would probably be required if A's border were long enough to require multiple ways? This has been a problem with rendering rivers in the past (and coastline, but that's been worked around) --Hawke 21:29, 25 March 2008 (UTC)

• According to my proposal, C would be added to the relation of A as inner and B as outer. But i think now we should rename the role of outer. I tried to keep it the same as the multipolygon but it doesn't really make sense when you think of it. Then outer would be called enclave. So that makes that border C would be added to the relation of A as inner and to B as enclave. That makes more sense to me. --Skywave 07:53, 26 March 2008 (UTC)

--- other description ---

• exclave - this area does not belong to the area which surrounds it
• enclave - this area belongs to an area which is not touched

--Mikes 19:00, 23 June 2008 (UTC)

This doesn't make it any clearer, because if you switch those two it is still true. Any piece of land that is an enclave is also an exclave. What you call it, is not dependent on the topology, but on your perspective. A piece of Belgium completely surrounded by the Netherlands is called an exclave from the Belgian perspective and an enclave from the Dutch perspective. (But to muddy the waters: In this specific case, the locals never talk about exclaves. They call everything an enclave.) --Cartinus 13:48, 29 June 2008 (UTC)

Is it even needed to talk about exclaves and enclaves on this page? To me it doesn't look like they need special treatment at all. Sure, from a person's viewpoint it looks different, but all we need is a way to make a boundary for a piece of land. Just make sure you define the roles of the way in the relation so that you know on which side of the border the country is (read: left/right should be sufficient IMHO). --Eimai 14:12, 29 June 2008 (UTC)

A boundary usually is ONE closed way to form an area. With en/exclaves you will have at least TWO closed ways to form TWO areas, which the relation has to know about. Assume we have 3 areas A,B and C. Area B ist totally enclosed by area A. Area A excluding area B is one 'state' and the second 'state' is formed by B and C. Now you have two relations. The first relation is area A excluding the 'enclave' area B. The second relation is area C plus the 'exclave' area B. It is right, that area B is an exclave and an enclave, but it is an enclave in one reltion and an exclave within the other. Thus the role is depending from the point of view. --Mikes 21:25, 21 July 2008 (UTC)

Anyway, the exclave and enclave role for this relationship should be completely removed as it just doesn't make sense to have them, and they're not well defined anyway. If you know the boundaries you can make up the rest of it anyway (you don't need left/right roles even). There's for example a municipality in Belgium which is just split in two, as they thought it would be nice to have the big avenue that goes straight through it a part of the municipality of Brussels. There's no enclave/exclave there, just two parts which are equal. There's no reason why in the case that one part is significantly smaller that we should treat that differently. Hence I'm removing the exclave/inner roles from this page. --Eimai 12:05, 31 October 2008 (UTC)

What about include/exclude? This is easier to understand. Mainly we mark the main area, than we mark a border for areas to include but are not inside the main poligon, than we mark a border for areas to exclude, which are inside any of the poligons we now have. BTW, a boundary is not necessary ONE closed way to form an area, but a serie of ways making up all the parts of the boundary, together forming a closed way to make up the entire area for the boundary. --Skippern 07:32, 10 December 2008 (UTC)

Similarities to IS_IN

The potential overlap between this relationship and the Is In relation could see many duplicate relations, one defining the boundaries of councils/states/suburbs/postal codes/counties/whatever and one containing all the individual points/ways within the very same defined boundary.

Perhaps a single relation which can define boundaries and contents all in one would be more reasonable??

• You could also add the relation of the boundary to the is_in relation. That would seem a bit more clean to me

Why not use the boundary relation which forms an area to decide what is 'is_in'? This could be automatic computed and would not need need the is_in of every single tag that should be 'is_in'. 'is_in' could not be forgotten. Michael

I have been thinking about this for a while and you are absolutely right, I can't find any reason why when boundary relations are done well there would be any need to the is_in relation (or the error prone individual tags) at all. Sure it's computationally a little heavier to have to work out everything that lies inside a large polygon, but compared to the human effort that has to go into managing the is_in style system it wins hands down. Especially with the upcoming 1000 member limit to relations, I already have a suburb with over 600 members in one of the is_in's I've experimented with, they will break the limit soon enough. --Beldin 11:59, 8 January 2009 (UTC)

I'm not clear on how this would/should be used

I'm a little unclear on tagging boundaries. I created a bunch of inclusive boundary ways in Paris for the various arrondissements, and I guess you (User:Skywave) deleted them. I'd like to do this correctly, or to collaborate on figuring out what correct should be. thanks. -- Mark 15:24, 7 July 2008 (UTC)

OK, I've figured this out now. I've found that I can do this to reproduce boundary relations as ways:

 <?xml version="1.0"?>
 <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
       xmlns:xlink="http://www.w3.org/1999/xlink"
       xmlns:svg="http://www.w3.org/2000/svg" >
   <xsl:output omit-xml-declaration="no" indent="yes"/>
   <xsl:param name="border"/>

   <xsl:template match="/osm/relation">
       <xsl:if test="tag[@v=$border]">
           <way visible="true">
               <xsl:for-each select="member[@type='way']">
                   <xsl:variable name="wayid"><xsl:value-of select="@ref"/></xsl:variable>
                   <xsl:for-each select="/osm/way[@id=$wayid]/nd">
                       <nd><xsl:attribute name="ref"><xsl:value-of select="@ref"/></xsl:attribute></nd>
                   </xsl:for-each>
               </xsl:for-each>
           </way>
       </xsl:if>
   </xsl:template>

 </xsl:stylesheet>

I think maybe we should add something in osmarender.xsl to take these relations directly to SVG. Unless of course somebody has already done that, which seems to be the case whenever I ask for something on OSM.  ;) -- Mark 08:20, 11 July 2008 (UTC)

• • It is true that is used this form in Paris. Before i did it there was a mess of all kinds of systems used by different people, so i made them more in line with the boundaries of the "regions" and "departements"

Add the node place in the relation

Almost all administrative boundaries have a related city/town/village as the place representing the administrative level. I would suggest to add the node place=* as member of the relation:

Way or Node	Role	Recurrence?	Discussion
	centre	zero or one	the node considered as the administrative centre (usually the node tagged with place=city/town/village)

Deprecates the capital=yes/country/province proposed here.

The same place node can be attached to many administrative level relations. It can also help renderers for the prioritization of name places display.

See my proposal here Proposed features/add center in Relation:boundary -- Pieren 16:55, 2 December 2008 (UTC)

See also proposal Relations/Proposed/Region --Jakubt 22:25, 28 August 2009 (UTC)

This has been standardized as the role "admin_centre" (normally a node), not "centre". < (Please use this spelling only in tagging)

There's a separate proposal for adding a node with role "label", to be used to locate the appropriate string (possibly abbreviated and formatted to better fit within the boudary (because not all boundaries are convex, the center used to display the name of the boundary sometimes falls outside the inner part of the bounded area, within a hole or between a main area and an exclave, the center is not the best place to locate this drawn label). Separately, the administrative center ("admin_center" role) will not necessarily be centered in the area (and it may even happen it is in fact outside of it, in another nearby area where it creates an exclave). A label can only be a single node, an admin_center may be a node, a closed way, or a boundary for a building or set of buildings and fields. Verdy p 08:44, 9 August 2011 (BST)

Use type=multipolygon instead

Each administrative region is in fact a multipolygon (i.e. a number of one or more areas which may each have zero or more "holes"). I suggest that we use the standard multipolygon relation for boundaries, and just tag it "boundary=administrative". This would be in line with other uses of multipolygons; for example, if we have a forest area, we do not create a new relation "type=forest" for this, but instead we just use "type=multipolygon" and tag it "natural=wood" (or "landuse=forest").

Multipolygon relations are a kludge for the missing area/polygon/multipolygon data type in our data model. If we had such an area type, we would of course simply use that area type to describe boundaries/administrative areas. So it is only logical to use plain multipolygons for administrative areas.

Multipolygons now support multiple disjunct areas as well as holes, and their borders can be made up from any number of ways (see Advanced Multipolygons), so they're a perfect fit for administrative areas.

This would also get rid of the rather complex notion of enclaves or exclaves; you would simply tag "inner" and "outer" boundaries as with any multipolygon. In addition, software that deals with areas of all kind will only have to support type=multipolygon for all kinds of areas, instead of having to carry a list of which relation types are actually areas.

Instead of	Use
type=boundary	type=multipolygon
role=enclave	role=inner
role=exclave	role=outer
role=(empty)	role=outer

Everything else (boundary=administrative, admin_level=x) remains unchanged, as multipolygons are designed to receive additional tags that say what the multipolygon actually is meant to model. -- Frederik Ramm

Note - mapnik currently doesn't handle this scheme well. This is because osm2pgsql adds all tags on outer ways to the relation's area - as would be expected for most multipolygons, however this is not wanted for boundaries, since we can correctly use roads as part of the boundary. --Thomas Wood 20:39, 1 February 2009 (UTC)

Funny, as I just wanted to mention this problem as well since I just noticed the awkward German boundary. Anyway, I can't really see why this should be merged together with multipolygon. As you see, the rules to handle them aren't the same. --Eimai 20:58, 1 February 2009 (UTC)

I have to agree this idea doesn't really work, the way boundary's map their data back to the individual ways is different to how a multipolygon would do the same, since in most cases a multipolygon will be mapping 1 set of tags back to each way. The boundary will, in most cases, map 2 (or some other even number) sets of tags back to the same ways, so they don't go cleanly, special handling will have to occur and if you are going to have a special sub-category of multipolygon to handle it, why not just have a different relation type. Surely a short list (2 at this time) of types of relations that have the inner/outer/enclave/exclave type handling of ways into loops but are have slightly different handling at other levels would be clearer. After all multipolygon really seems appropriate for mapping a consistent area that is all the same, which a boundary isn't it's more a surrounding of many different things to group them together. --Beldin 09:55, 5 February 2009 (UTC)

Can we now happily start using normal boundary relations again instead of going back to multipolygons please? There's zero advantage of using a multipolygon here. Rather, it's even harmful, as renderers that can handle multipolygons, suddenly have problems with the "boundary multipolygon". So while trying to achieve consistency, using multipolygons here did exactly the opposite and showed that boundaries can only be handled if you make them a special case. And if you need to handle boundary multipolygons in a special way, just start using boundary relations again, so the multipolygons which are tagged like a multipolygon can all be handled consistently. --Eimai 11:52, 9 July 2009 (UTC)

There is one really ugly ambiguity in the type=boundary schema: It does not distinguish between the multipolygon area of an (administrative) unit like a country, region, etc. (e.g. relation #9407 "Andorra") and just a part of the polygon's line (e.g. relation #51239 "Deutschland - Schweiz"). In both cases, such a relation is tagged with type=boundary and there is no way to disambiguate these two differnt cases. When using type=multipolygon for areas (even when they are countries), things get much clearer.

I know, there is no impact on neither mapnik nor osmarender rendering since both only show border lines, not the enclosed areas. But I suppose OSM's goals are not only rendering its own maps, but providing a free data set. That's my point. We on Wikivoyage intend to render our own maps based on OSM data. We will need overview maps (like this one) where one country is empathized from its neibours by a differnt color. In order to archieve this, we need to know about areas i.e. multipolygons, not just lines.

Well, that's the geometrical aspect. As far as tagging inheritance, I think it would not be too hard to explain osm2pgsql to handle boundary multipolygons somewhat different from others.

Conclusion: strong support for Frederik's proposal. Please do not "happily start using normal boundary relations again".

-- Hansm 17:37, 21 July 2009 (UTC)

Well, scrap that ambiguity argument, relation 51239 isn't mapped like a boundary relation should be mapped. A boundary should include all the ways around the entire area the border encloses.

From a data point of view, it only makes sense to have boundaries not like multipolygons in the database as the two concepts are completely different. From a tagging point of view it makes sense because there are special tagging rules for the boundary multipolygon compared to the normal multipolygon, and for a data handling (rendering and in general using the data) point of view it makes sense because you need to first of all think about it and then care about writing special rules to be able to use the data correctly.

So far, the only argument pro I hear is: "a country looks like a polygon". Yes, that's indeed true. But it doesn't look like the OSM concept "multipolygon". So don't use it that way. --Eimai 18:18, 21 July 2009 (UTC)

I'm sorry if I missed the point, but could you explain your "But it doesn't look like the OSM concept "multipolygon"". What's that concept ? The frederik point looks logical, and I don't see a case where a admin boundary couldn't be mapped as a multipolygon. Is this about previous posting saying that a way belonging to a multipolygon relation got it's tag inherited from the relation ? Is this a established concept or only a osm2pgsql issue ? (sorry for breaking through open doors if I do)Sletuffe 21:57, 22 July 2009 (UTC)

Well, as I said above: tagging a boundary relation as a multipolygon would require special exception rules to handle them correctly in all areas: they need special tags which are interpreted differently than all other multipolygons (a multipolygon will have no tags in the relation, other than its type, and will use the tags of the outer polygon to put them into the polygon type in the database, where the boundary multipolygon would suddenly have a number of tags in the relation and the tags on the outer boundary would suddenly have to be discarded), then after that they require special rules to handle them when rendering, failure to identify and taking specifically care of that results in bad maps.

So the need for a different way of tagging and the need for a different way of handling the data (and specifically: the failure to do so resulting in bad maps) means the two concepts are different and shouldn't be merged. --Eimai 12:50, 23 July 2009 (UTC)

Thanks for the explanation. What I was thinking about is "advanced multipolygon", the page suggest that properties of the area should go in the relation (That "outer way olding the tags" thing looks like the real problem to be), and let ways have the tags they need, or even no tags at all. The type=boundary could then be replace by a type=multipolygon (of sub-class advanced multipolygon, guessable by it's boundary=administrative property)

But I admit, this looks like a bunch of change for few advantage. Sletuffe 14:06, 23 July 2009 (UTC)

I'm just about to dig myself through the 100GB+ database imported from the planet.osm dump. So, my focus is on the DB structure rather than on the daily work of mapping. What I see is that the very most of the boundaries are simple ways, not relations. Among those which are relation, both, the type=boundary and the type=multipolygon scheme have about the same frequency. I do consider them as pioneer work and not as the normal case. However, using a relation like a bracket around way segments that form a part of the border line (as relation 51239 does) seems reasonable to me. Otherwise, everything had to be done twice: once for the country on the left hand side of the border line and once for the right hand side. This results in the double maintenance work and thus would be more error prone.

But well, if you really would use the type=boundary tag only for closed relations, this would be consistent, too. The actual problem is that both attempts are mixed up.

-- Hansm 19:26, 21 July 2009 (UTC)

(moved from in between Eimai's posting to down here in order to keep the discussion readable -- Hansm 15:19, 22 July 2009 (UTC))

Well, I have created such not-closed type=boundary relations (to mark a boundary between two countries) The main reason was technical : France was more than 2000 members and excedeed API limits, and because it was just unusable being that big.

Therefore, I constructed a type=boundary relation made of other type=boundary relations that makes a closed way in the big one.

The other point, is : once I have constructed the Italian/france boundary, that relation can be used in both Italian and france admin area.

As of the statement "there is ambiguity", I would say that not completely. By watching the tags, you don't know exactly if it's a closed or open area. But osm2pgsql (or other tools constructed for that) do check for closed outer/inner ring (so, it's programaticly feasable to solve this ambiguity)

For the multipolygon VS boundary, since germany as proven feasability with multipolygon, I support Frederik's proposal to minimise redoudancy Sletuffe 12:29, 22 July 2009 (UTC)

@Sletuffe: I have understood pretty well why you have braced logical segments of the border line like "Italian/france boundary" into a relation. And I think it's sensible. The only bad thing is that you have tagged it as "type=boundary", what is definitely against the definition of that tag. "type=boundary" is reserved for closed areas, not for segments. Everything would be fine if there either were no "type" tag at all or perhaps some new type, say "boundary-segment".

osm2psql does not check relations with "type=boundary" for open/closed rings at all since boundaries are always converted into PostGIS LINESTRINGS rather than into POLYGONS. But even if osm2pgsql would, producing ambiguities that some tool has to fix is not a good style. It makes the DB hard to use. By the way, I did not use osm2pgsql for my import since it is too much focused on standard OSM maps. I did it with an own import tool.

-- Hansm 15:19, 22 July 2009 (UTC)

Update: After having read Relation:boundary again and also section Non-closed ways? on this talk page, I think I begin to understand what the actual crucial point is: There seems to be a big confusion whether relations with "type=boundary" are reserved for closed areas or whether they are also applicable for parts of the enclosing edge of the area.

Relation:boundary seems to talk implicitely about closed areas, but it's never said clearly. However, roles like "enclave" and "exclave" only make sense for areas, not for lines.

Maybe some of the hard core mappers should make the description in Relation:boundary clearer. Me, as a newby, hesitate to do it myself ;-)

-- Hansm 16:21, 22 July 2009 (UTC)

Your statement about osm2pgsql is wrong, it does convert type=boundary to GIS POLYGONS if they forme a closed ring.

(It will drop in some cases orphan linestring and import the polygon anyway) Sletuffe 17:17, 22 July 2009 (UTC)

Yes, you are right with osm2pgslq. Anyway, better using a proper tagging scheme right from the beginning than letting tools clean up the chaos. -- Hansm 17:31, 22 July 2009 (UTC)

True, that would ne much cleaner, I like your previous idea over there creating a new type called "type=boundary-segment". That would lower the burden on "GIS constructor tools" and make it cleaner for tool checker, human mapping and prevent manipulation of +2000 members relations.

As for the "do we modify the wiki" I suppose that we should check if people have used it in linear boundary segment and at least warn that it "should be used" only on closed rings. Discussion might lead to making it clearer. I'm in favor of that modification. Sletuffe 21:51, 22 July 2009 (UTC)

Fine, so we are at least two ;-) But seriously, I think introducing a "boundary-segment" tag would solve a lot of confusion and dispute. I have imported the planet.osm dump from about 10 days ago into my DB. Thus, I have direct access to the database, but I still have to figure out a suitable query for finding out how many boundary-segments are tagged as boundary. So far, I only have searched for admin-level >= 3. In this levels, segmented boundaries are used for France, Germany, Austria, Switzerland and some other European Countries. I will check out more details tomorrow. -- Hansm 22:41, 22 July 2009 (UTC)

OK, there is some statistics on User:Hansm/Boundary statistics. -- Hansm 12:05, 23 July 2009 (UTC)

There may be a catch here: not all boundaries are finished yet, and we have a number of type=boundary relations in Belgium which are still open, since we don't have sufficient data to close them. --Eimai 12:26, 23 July 2009 (UTC)

I see. Anyway, my statistics only bases on tags and relation members. I'm not yet able to check for closed ways. But just to let me know, how big are these gaps? -- Hansm 12:58, 23 July 2009 (UTC)

For Belgium, check WikiProject_Belgium/Boundaries. The only closed boundaries are those marked with green. Red ones don't exist and yellow and orange ones have gaps. --Eimai 14:28, 23 July 2009 (UTC)

I have changed the wording a bit so that it's clearer that type=boundary is made for closed areas. Feel free to revert if that's not the case for someone. Sletuffe 14:18, 23 July 2009 (UTC)

I am not convinced. I still advocate the use of multipolygon relations. The comments by User:Eimai are not valid and obviously a consequence of either his mis-understanding of multipolygons or perhaps the evolution of the use of multipolygons since the above was written. If he were right in saying that boundaries and, for example, forest multipolygons required different algorithms and special exceptions etc. then he would have a point, but fact is that boundaries and multipolygons are processed just the same. A boundary relation does not require special rules. It is not true that multipolygon relations do not have any tags on the relation. It is not true that multipolygons automatically use the tags from their outer rings to give meaning to the multipolygon - for example, a forest multipolygon might as one of its "outer" ways include a road which borders the forest, but the forest would not therefore have a "ref" or "maxspeed" tag. It is perfectly ok to use multipolygon for a boundary. The "enclave" and "exclave" roles can be replaced by "inner" and "outer", respectively. It is also not required for multipolygons to have roles; anything without a role will be assumed to be "outer", so there is no compatibility issue.

My reasoning remains unchanged; in my opinion, multipolygons already demand a lot from renderers and other processing software, and special rules have to be implemented to comibine multiple linestrings into one coherent area. Let us not increase that list - "multipolygon" means that an area is to be created by using these algorithms (see Relation:multipolygon/Algorithm) and any other relation type means it is something else. There is absolutely no need for mappers and users to deal with a second relation type which essentially means the same. --Frederik Ramm 12:56, 3 April 2010 (UTC)

It became true because the multipolygon page was changed a lot since the first comment of this thread. I would say that multipolygon's description is now like boundary was ;-) So, I support this, there are no reasons to use type=boundary (except inertia) as it means and is constructed the same way. sletuffe 13:15, 3 April 2010 (UTC)

Whereas the current database clearly shows that the usage of roles now adopts multipolygon form (I changed the page accordingly and immediatelly go trouble with sletuffe) it seems the suggestion to use type=multipolygon has not been accepted equally. Also between multipolygon and boundary are still slight differences (i.e. boundary describes an area as well, but the main focus is of area border, where multipolygons main focus is on the area itself). I would suggest to use type=boundary with semantics identical to multipolygon in future and call type=multipolygon as well as old roles (enclave/exclave) as deprecated. This would help to clear situation and unify database. The important goal that multipolygon and boundary use same semantics has been reached. --Stoecker 12:23, 30 May 2010 (UTC)

You have chosen to describe in this wiki page the current main usage in the database, but I really think you have read it rather quickly and I'm not agreeing with your findings. You said that the current database "clearly" shows the usage of roles adapted from multipolygons, and no, I contest those reading. The main used role is (blank) and neither outer nor exclave. So, no, it is not adopting multipolygon's form wich does not recommand (blank) while the current usage for boundary is to ommit the role when it is external. The same goes for relations of admin level n included in relations of admin level n-2. The current usage is to not include them in the containing relation. sletuffe 21:25, 30 May 2010 (UTC)

Blanks aren't really a good indication, as they have same meaning for multipolygon and boundary, they can be both (which is by the way another good point the consider them deprecated, as a blank role always means one needs to guess what is meant). Same situation for subarea. Whether it exists or not is no indicator what type is used. As I already said the omission of optional tags doesn't say anything at all. Anyway I don't have the time to fight useless fights over and over again each time I change the wiki pages. Eventually the pages evolve correctly or not, more and more often I tend to don't care. Last time I tried to fix problems another user changed everything back several times for several others doing the same. After some weeks others finally fought him back and the page now has a valid definition (which really surprised me). I don't intend to do that again. So probably I stick to defining JOSM and don't care about MapFeatures at all. --Stoecker 22:19, 30 May 2010 (UTC)

This exact reason, they're using the same semantics, is the underlying sentiment to move to multipolygon. They mean the same thing, they describe the same concepts. Why do we need to call this concept by two different names? A multipolygon has an outer edge, same as a boundary. Both mean the same. Both describe an area as well as the boundary. Anyway, we're running around in circles here. --Ldp 00:05, 24 June 2010 (UTC)

Stats: type=boundary: 64710, type=multipolygon: 14461, Roles can be found in Tagwatch linked from the page itself. --Stoecker 22:23, 30 May 2010 (UTC)

These counts might seem obvious at first sight, but they don't represent a possible adoption uptake of multipolygon over boundary. Plot it over time, and it might be more clear which direction this is heading. --Ldp 00:05, 24 June 2010 (UTC)

Giving a new point of view - Merging everything in type=multipolygon makes automatic validity checking harder. I now implemented relation checking in JOSM's validator and this checker checks for multipolygons whether they have outer/inner or something else. Now boundaries also use admin_centre and subarea. To get this together I either need to allow these roles for all multipolygons or need to add checks which will fail for every new type. The problem with type=multipolygon as generic area type is, that we don't specify that current multipolygons are plain geometric objects only, so I can't distinguish them from yet unknown upcoming types. I still think it is a better idea to have multipolygon as definition for the way how area types should be designed, but don't enforce the "type=multipolygon". For the implementer of area-drawing it is anyway not different if boundaries are "type=x" or "type=y". He needs a style definition for known types and ignores unknown types in both cases.--Stoecker 17:50, 8 July 2010 (UTC)

What, the validator cannot check for the presence of the boundary=* tag when running these checks? The way you describe it, it will already flag 'warnings' for those boundaries already mapped as multipolygon. Not that helpful, I'd say. --Ldp 16:50, 6 October 2010 (BST)

For Europe we have now approx 120.000 type=boundary and 30.000 type=multipolygon today if my short view was correct. I would say the type=multipolygon for boundaries is not successful and we should deprecate to use it. --Stoecker 17:47, 22 November 2012 (UTC)

Non-closed ways?

When drawing boundaries, there's usually one thing on one side, and one thing on the other side. (Possibly more, if dealing with multiple levels of division). So, you can either draw one closed way around each entity, and have two or more overlapping ways at each boundary, or you can draw a single way between each "boundary junction". That to me sounds a lot more elegant. But the question is how to do that.

I'm having trouble understanding the boundary relation proposal, however, because people seem to talk about these boundary ways as if they are closed. If you're going to try to draw a closed way around a non-connected area, or an area with holes in it, then multipolygon makes perfect sense. But I don't think that's what the original point of the boundary relation was. My original understanding of the boundary relation was to group together a number of non-closed ways to make one (or more) closed path defining the boundary of some entity. Is this what other people are picturing, too? There are some who are saying that this is just a special case of a multipolygon, but I see a key difference: what other uses of multipolygon relations involve open ways? Vid the Kid 06:31, 22 June 2009 (UTC)

See illustration 6 in the advanced multipolygon definition discussion here. The boundary ways don't need to be closed for boundary relations. They don't even need to be tagged as boundary ways to be in a boundary relation - say for example a parish boundary runs along a stream then the relevant section of the stream way can be added to the boundary relation (or lane or road or whatever). --EdLoach 07:22, 22 June 2009 (UTC)

What about separating geometrical and informational part?

I like multipolygon, but I do not like to use it for everything what has "multipolygonal" shape. It is the same as if we used one Relation:polygonal_line for all highways, rivers, pathes, ... with tags like type=highway, type=river etc ... The reason for this is happenning here is because there is missing data structure "multipolygon", which would be continuation of sequence: node, path, ... So the cleanest way would be to introduce new data structure. Before (unless) this is done we should use Relation to model it somehow. As i said, I do not like the idea that every multipolygonal shape has type=multipolygon, because than the lack of this data structure results results in occupying very valuable attribute in these relations. The type of relation should be the most important information and it surely is not the shape of the thing modelled (see my argument with all path shaped features on map). Therefor we should model it differently. Here is one proposition: let's separate geometrical information in relation:type=multipolygon without many other tags and then let other relations to refer to it. For example if we agree on realtion of type=islandgroup than it would have tags like name=*, seismic=yes/no, etc... and one member which would refer to multipolygon defining its shape (yes the example is stupid, but you get the idea). --Jakubt 00:31, 29 August 2009 (UTC)

I agree with your analyse of the problem, but I don't find your solution the best way to go because it adds another level of complexity ( a relation having a relation ?)

The two solution I have are : with every type=* a supposed shape is defined (just like the way it is now) type=boundary is multipolygon shape, type=route is multilinestring, etc... and type=multipolygon should be replaced by another more explicit type=* (type=landuse, type=..., type=riverbank, ...)

Or, drop type completly and guess it from the way/relation members or from the other attributes

Example would be a relation like :

• landuse=forest
• name=Sharewood forest
  • ways or relations members with roles

( this makes the duplicate information like type=boundary + boundary=administrative simplified to just boundary=administrative ) sletuffe 09:27, 29 August 2009 (UTC)

recent 30/05/2010 changes

Since I'm not willing to enter an edit war, I'll let you review the last changes about exclave/enclave -> outer/inner and the new recommandation/possibility to add all sublevel administrative level into the relation that contains them. Of course, I'm all against. sletuffe 11:06, 30 May 2010 (UTC)

• I added some yomments on you users page. Actually I do not see where your problem is. --Stoecker 11:33, 30 May 2010 (UTC)

• Maybe we should put all that public for larger audience and gather different views than mine and yours ? sletuffe 12:27, 30 May 2010 (UTC)

• @Pieren: I choose "admin_center" over "admin_centre" as it is used more often (but only slightly). Let's hope that description on this page helps on of the two forms to win. "centre" is better form when thinking English I know :-) --Stoecker 12:47, 30 May 2010 (UTC)

Subarea?

Exactly what should be tagged as subareas (of a county, for example)? Anything completely within the boundary (cities, towns, city neighborhoods)? Only the next admin_level (cities, towns)? Or should cities that cross county lines be included in all county relations? --NE2 09:10, 19 June 2010 (UTC)

• In the database it is used to link to relations of "admin_level+1". See e.g. Czech republic. I also think this is enough, as it allows to link all levels of relations. --Stoecker 15:04, 3 July 2010 (UTC)
  • So if something of level 8 crosses a boundary of level 7, and is thus in multiple level 7s, should it be added to both relations as a subarea? --NE2 15:19, 3 July 2010 (UTC)
    • You have to ask yourself: Where does it sit in the hierarchy? Not all hierarchies are nice piramids. If a level 8 straddles the boundary between two level 7's then it most likely derives it's authority from something at level 6 (or above), so it would need to be a member of the level 6 (or above). Not from both level 7's. --Cartinus 11:20, 5 July 2010 (UTC)
      • So, in the US, counties would have no subareas, since cities are recognized by the states? What about those states where cities don't cross county lines? (And what about interstate parks, which are created by the states?) --NE2 11:31, 5 July 2010 (UTC)

Coincident boundaries of different types

Since the boundaries themselves need to be tagged with boundary=whatever, this would seem to preclude having boundaries of different types coincident. A national park might run along a national border, or a park and a native reserve might be adjacent. The problem is the redundancy of having the information on both the way and the relation. --Hai-Etlik 22:50, 30 June 2010 (UTC)

Merge with key:boundary

In my opinion, it would be better if this pages is merged with the page Key:boundary since they both talk about boundaries. In an introduction, the concept of different boundaries could be explained (like now explained on the "key" page). And the difference between a closed-way-with-a-boundary-tag and a lot of separate-ways-with-a-boundary-relation could also be explained. Followed by the tagging schemes for the 2 cases.--Sanderd17 22:47, 9 November 2010 (UTC)

Label role

I don't think Mapnik currently support the "label" role (if someone knows differently, please correct me). But if and when it does, what is the use case for this feature? Currently when someone draws a boundary for a place with name=ABC, they tend to drop a node roughly in the center tagged with name=ABC and place=*, where they wish the label to appear. They may or may not add it to the relation as role=label (currently it does not appears to make a difference; the rendering is determined strictly by the styles associated with place=* schema and the location of the node). A side effect of this approach is that there will be two objects in the Nominatim database for the same object on the ground: the boundary and the node with the same name.

I assume the introduction of the "label" role is to make the rendering of the label possible without the use of a place=* node. So is the idea to make the renderers draw the name of the boundary in a style consistent with the admin_level of the boundary at the location of the "label" node? Will it become unnecessary to tag the "label" node as place=*? What about name=* or label=*? It would be good to write down how the "label" node is to be tagged.

The purpose is for cases when the centroid of the polygon is not the logical center of the place, usually a city with an established downtown. --NE2 01:58, 21 April 2011 (BST)

Understood. But what kind of point will go there? With what tags? And what will the renderer be expected to do with it?

I don't know. --NE2 02:56, 21 April 2011 (BST)

I do agree that the "label" role should be accepted to include all names, alternate names and translations needed to reference an area and to display within it. Its placement as a node would allow displaying the label at another location than the centroid, or even at the position of the administrative center (which may not be central as well). If present, it would override the "name" property (which mat contain some technial precisions, not useful for displaying on the map, or just only one native name for the country/state/province/department/country/arrondissement.

The label lis also needed because many multipolygons are not always convex, and the default centroid may in fact fall outside of the inner area (notably if the multipolygon has some exclaves far away from the main area: it is still better to place the label in the center of the main area; or if the multipolygon includes a central hole, which is a separate area needing a clearly distinct label where the outer fing would fit a label moved slightly away from the center).

If a label is present, use it instead of the "name" (or "name:lang") property, to find the appropriate label to display (possibly in another language) and to place it correctly.

When a label is present, the name property becomes only technical, useful only for editing the map when looking for names (this "name" property coudl add some useful precision to discriminate between homonyms of distinct places: such precision could be like in Wikipedia article names, the name of a containing area, an administrative level, and so on, not very useful to display when rendering the map. The label should be optional.

Note: currently the renderers are displaying BOTH the "name" property of the area (at its centroid), and the name of its administrative center. This unnecessarily creates duplicate labels. To determine which label to use, use these in order of priority:

1. the "name" (or "name:lang") property of the "label" member (this should only be a node), centered at the position of that node;
2. the "name" (or "name:lang") property of the "admin_centre" member (usually an admin_centre is a node, in that case use this node position; but this could be a building, or complex area, and so it would also be a multipolygon, and in that case use the centroid of that building for positioning that label; but if the polygon defined as the admin_center also has a "label" member node, use it instead of computing the centroid of that building);
3. the "name" (or "name:lang") property of the area itself, positioned ats its computed centroid.

With this, we would avoid all those many duplicate names occuring in many rendered maps (depending on zoom level).

Verdy p 23:50, 8 August 2011 (BST)

Is this used for areas/regions or boundaries/lines?

It is very confusing :-( —Preceding unsigned comment added by Jakubt (talk • contribs)

It's used for boundaries that enclose areas. --NE2 00:06, 3 July 2011 (BST)

Way Tags, and Multipolygons as members

Firstly "Way Tags". I've recently been adding these where they are "missing", but if the relation is well-formed they aren't really needed, as has been pointed out to me by a number of people who created the relations and wondered why I was adding them (I pointed them at the wiki). I agree that they aren't needed, though have found them useful while fixing broken boundaries recently. Should we amend the page to stress that way tags are optional, or even unnecessary when the relation is complete? -- EdLoach 16:30, 5 August 2011 (BST)

Reading your question one year later ;-) : I'm in favor of, at least, explaining that once the relation is complete, tags on ways "could be" removed. Or, that if someone enters in one run a complete relation for one administrative entities, adding tags on ways is only optionnal. sletuffe 12:36, 14 September 2012 (BST)

Yeah, tagging the ways, if you have a nice and complete/closed relation, seems like unnecessary duplication of data. It also affects the standard OSM Mapnik rendering making borders heavier as it applies the border style multiple times if both the relation and the way has boundary tags. I never tag the relation member ways (except for perhaps source tags and a note not to remove the way) and I fully support adding the "optional" wording to the "official" documentation Joakim Fors 21:02, 28 October 2012 (UTC)

Secondly, should multipolygon relations be allowed as members of boundary relations (whatever type tag is used)? An example where I have seen this done is where the island of "Mainland" is added to the "Orkney" administrative boundary relation. The alternative is to add all the members of the Mainland relation to the admin boundary relation as well, but should this be necessary?

-- EdLoach 16:30, 5 August 2011 (BST)

I would say that yes because it's simpler for mapping in some cases. But AFAIK this isn't supported well by consumer tools. sletuffe 12:36, 14 September 2012 (BST)

enclave/exclave roles no longer used

Just a quick note. The enclave/exclave roles are no longer in use in the current osm database. I've cleaned up the last few usages of that roles. see taginfo roles --Werner2101 (talk) 11:01, 9 March 2013 (UTC)

I removed them from the implementation notes, but imo they should stay in #Relation members, so it's easier to understand an object's history. --rayquaza (talk) 14:18, 21 November 2013 (UTC)

Admin Centre as a way

Under Relation:boundary#Relation_members it says that only node type elements are valid for the role of admin_centre. However it seems to me that for lower level admin levels, for instance a village, the administrative centre might be building, which could be tagged as a way rather than a node. Dmgroom (talk) 12:08, 12 November 2016 (UTC)

Fully agree. Have a number of townhalls here that are the admin centre. There is a rendering flaw in Carto though, see issues in carto, and osm2pgsql.--Polarbear w (talk) 21:29, 25 January 2017 (UTC)

Support this. The admin centre in reality is the place where all the administrative decisions are taken, which is specifically the parliament, townhall or the council building --Planemad/Talk 05:50, 31 March 2017 (UTC)

For example if a city is a capital of country, given the city might be mapped as an area and not just a node, I think it should be the city relation which is the admin_center, which in turn has the label node, so any type should be okay as the admin center. --Aharvey (talk) 03:41, 18 September 2020 (UTC)

I fully agree. The current solution leads to double city entries in OSM, because people add nodes as a caity although the city already exists as a way/boundary. -- DerGuteMercator (talk)

Multiple Admin centres

Some boundaries need several admin_centres, not just one; they may be very far away from each other. Countless examples worldwide, including for some country capitals, or religious boundaries co-located in two cities in their shared area. Generally these admin_centres are splitting the responsabiltiies that other areas merge into one (e.g. government of authority, seat of the head of authority, judiciary head, public access, management office, ceremonial, or specifically for some services in municipalities such as birth/residence/death registration, celebration/registration of marriages/unions, taxes, meeting place for the council...), but sometimes this is not even the case as both locations have the same roles (possibly rotating from one location to another on some prefined schedule). Even when roles are distinguished it is not evident to claim that one is more important than another (and we don't have any way to specified "subroles" except by tags on the referenced place node or building or rea with multiple adminsitrative buildings).

When the boundary is a city/town, however, if there are multiple locations, they are frequently for more local services in subdivisions. But this is not true for larger boundaries. In smaller boundary areas, a single node is generally enough (but not that an "admin_centre" is not necessarily pointing to the exact location of an effective administrative service, but can be located nearby (e.g. on a square or garden near the office buildings). Also not all boundary items have their own adminsitration, so the admin_centre is just pointing in some "central" location, generally in the most densely populated area near a central crossroad where most people in the area are visiting or going to.

With more and more administrations going online (for services or even for the meeting of their decicing councils), many offices are no longer needed for the public, so multiple administrative authorities may decide to merge their admin offices in the same location or externalize many services to another service outside their area (this does not mean that they no longer exist and don't have their own electoral areas: councils are still elected separately, and their will still be local polling stations (often multiple ones per city, but not necessarily aligned with administrative subdivisions: these separate polling stations are still used for the same elections and so are not admin boundaries)

Let's give some examples with multiple admin_centres: Bolivia, South Africa, Israel, Galicia (Spain)... — Verdy_p ^(talk) 21:55, 25 January 2017 (UTC)

Are boundaries still rendered based on the way's tags?

The page states that boundary ways are only rendered based on the tags of the way, which would require, say, U.S. county lines to be tagged with boundary=administrative and admin_level=6 in order to be rendered. However, this doesn't seem to be the case. I added the township boundaries to Lebanon County, PA without these tags on the ways, and they render as intended. Was this once true, i.e. when Mapnik was the default renderer on the main site?

--Roadsguy ^(talk) 20:02, 8 July 2017 (UTC)

As of now, most map styles, including the standard Openstreetmap-Carto style, use the relations. However, tags on maritime boundary ways are still used to distinguish land borders from ocean borders in some styles. --Jeisenbe (talk) 00:30, 2 June 2019 (UTC)

Should type=land_area and land_area=administrative be mentioned?

This page has included text about a tag land_area=administrative for a number of years, but this tag is not documented.

"If you have a land-locked administrative area in the you should set both: boundary=administrative and land_area=administrative. If the land_area is not the same as the boundary, make two relations, one with land_area=administrative and one with boundary=administrative."

Taginfo's map shows it is only used frequently in Canada and Libya, though there are a dozen others: https://taginfo.openstreetmap.org/tags/land_area=administrative#map

Does anyone know how this tag is used by mappers? Is it being used by any database end-users? --Jeisenbe (talk) 00:30, 2 June 2019 (UTC)

I am going to remove mention of land_area from this page in a few days, since it has been 2 months. --Jeisenbe (talk) 13:28, 31 July 2019 (UTC)

Jeisenbe: And now it has been 2 years :). I also spotted it in the last rewrite, but did not remove it. I think it's long overdue -- who will do the hono(u)rs? Duja (talk) 15:24, 13 May 2021 (UTC)

Generic boundaries versus administrative boundaries

After reading this page, it appears that aspects of the article appear to be specific to boundary=administrative rather than giving general guidance for the boundary relations. I would suggest that aspects that are specific to administrative boundaries be appropriately moved to that page. For example, the relation role "admin_centre" as far as I know only applies to administrative boundaries, and there are other such examples scattered throughout. The page should either be corrected to properly separate boundary relation concerns from administrative boundary concerns OR the page should be made comprehensive enough to properly describe the various types of boundaries. I am hesitant to jump in and start editing a page that describes a key with >8M usages but there appears to be problems here. ZeLonewolf (talk) 19:56, 18 October 2020 (UTC)

is it OK to use relation as inner?

"Boundary relations can be topologically and logically nested within one another, and thus share some ways." - is it OK to for boundary relations to be nested in each other?

And inner being a relation, not a way? Note that https://wiki.openstreetmap.org/wiki/Relation:boundary#Relation_members and "and thus share some ways" conflicts with "Boundary relations can be topologically and logically nested within one another"

Or is it about boundaries being nested within one another - not about boundary relations representing them being nested within another ones? Mateusz Konieczny (talk) 17:49, 18 August 2021 (UTC)

I edited it a bit in https://wiki.openstreetmap.org/w/index.php?title=Relation:boundary&diff=2188662&oldid=2152922Mateusz Konieczny (talk) 18:02, 18 August 2021 (UTC)