[Talk-ca] Maritme borders in Canada

richard at weait.com richard at weait.com
Mon Jan 5 02:34:42 GMT 2009


Our German colleagues have just proposed a new method for tagging
boundaries / borders.  I'll quote them here and direct you to find the
original thread on talk for comment and discussion.

First an email from Frederik, then one from Jochen.  They both relate to
borders and maritime borders.

Best regards,
Richard


Subject:   	[OSM-talk] Using multipolygons as boundaries
From:   	"Frederik Ramm" <frederik at remote.org>
Date:   	Sun, January 4, 2009 4:08 pm

Hi,

    those of us who use relations to tag administrative boundaries
usually apply the schema described in

http://wiki.openstreetmap.org/wiki/Relation:boundary

which suggests to use a type=boundary relation with "enclaves" and
"exclaves". At the time of conception, that was ok because
administrative areas (e.g. countries) often required border lines taht
consisted of many ways and exclaves, something that plain multipolygons
did not support.

Since we now have "advanced multipolygons" as described here:

http://wiki.openstreetmap.org/wiki/Talk:Relation:multipolygon#Advanced_multipolygons

(which, being true to their name, support any number of disjunct areas
which may have zero or more holes each, and even islands in holes and so
on), there is an equivalence between the two: each administrative area
corresponds to exactly one multipolygon.

I am thus suggesting that we drop using the special "type=boundary"
relation and instead use a simple "type=multipolygon" for administrative
areas. Everything else would stay the same (boundary=administrative,
admin_level=x, name=y, ...). Members would not carry the roles "exclave"
and "enclave" (which seem to have been difficult to understand for
some), but instead simply "outer" and "inner" just like with plain
multipolygons.

I have described the suggested change in detail here:

http://wiki.openstreetmap.org/wiki/Talk:Relation:boundary#Use_type.3Dmultipolygon_instead

The main advantage of this is that any piece of software that works with
our data would just have to understand multipolygons - wheter they are
additionally tagged as representing a boundary, a forest, a lake or
whatever - instead of having to carry a list of relation types that form
one or the other kind of area.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"


Subject:   	[OSM-talk] Comprehensive proposal for tagging of boundaries
From:   	"Jochen Topf" <jochen at remote.org>
Date:   	Sun, January 4, 2009 5:47 pm
To:   	"Gustav Foseid" <gustavf at gmail.com>
Cc:   	"osm" <talk at openstreetmap.org>
Priority:   	Normal
Options:   	View Full Header |  View Printable Version

On Tue, Dec 30, 2008 at 10:32:45PM +0100, Gustav Foseid wrote:
> I would suggest that maritime borders are not tagged the same way as land
> borders. Should we have a new tag for maritime borders? Stop tagging them?
> Ignore the problem?

We had the same discussion on the talk-de mailing list. There are
several things here:

a) We should move away from tagging the ways of the boundaries with all
   sorts of stuff and move this information into relations. This is much
   cleaner and allows different kinds of borders to co-exist on the same
   ways.

b) Some people need borders on the water, the "official" borders of
   whatever entity we are talking about. Others would prefer to use the
   coastline as boundary. Clearly there is a need for both.

So here is the proposal for how to tag things: (This also ties in with
Frederiks post about type=multipolygon vs. type=boundary.)

All boundaries are made up out of ways. Those ways are tagged with
boundary=administrative. Where the boundaries go out on the water, the
ways go out on the water and are still tagged with boundary=administrative.

All ways belonging to the boundary of some entity are put together into
a relation tagged with
    type=multipolygon
    boundary=administrative
    admin_level=<something>
This includes the ways going out into the water.

Boundary ways are shared between several levels of administration. So if
a border is a country border and at the same time a state border, the
way is in two relations, one for each. Exclaves and enclaves can be
modelled with the multipolygon relation without any problems. (See
Frederiks post for details.)

If there are several relations on the same ways, the admin_level for
those ways is the one with the smallest number (ie. the highest
administrative level). This is redundant, but it allows renderers to
ignore the relations for many cases and just render the ways. Borders
will show up as they should with more important borders drawn instead of
less important ones.

There is a second relation for every administrative entity. It contains
all the boundary ways on land plus the coastline connecting those points
where the boundary crosses into water. So it is the land area of this
administrative entity. It is tagged as
    type=multipolygon
    land_area=administrative
    admin_level=<something>

So if you are interested not in the boundary on the water, but just want
the land area, you use this relation. For entities that are completely
on land only one relation is used and it is tagged with both:
    boundary=administrative
    land_area=administrative

In the land_area relation islands will show up as seperate areas. But
they are still in the same multipolygon relation.

Note that this proposal only gives you a way how to tag maritime
boundaries and have the land area, too. It does not say where those
boundaries are supposed to be and whether one or the other makes more
sense, thats a different discussion.

This proposal is mostly backwards compatible with existing use. If
existing borders are on the coastline, they can stay there until
somebody wants to change it. Relations have to be added in those cases,
where they are missing. Some existing relations will get extra land_area
tags, some new relations for land_area will be created. The biggest
change is from type=boundary to type=multipolygon, but see Frederiks
post for that.

Jochen
-- 
Jochen Topf  jochen at remote.org  http://www.remote.org/jochen/  +49-721-388298









More information about the Talk-ca mailing list