Re: [OSM-talk] Administrative boundaries export
Well, I think I fully understand all the diversity, but when you want the "shape of UK" or Liberia, I presume most people expect the land, not the maritime boundaries claimed ones or whatever. This does not prevent to have 2 boundary relations, one for land boundary and one including maritime ones (that's the case for France for example + one including overseas land), but make sure the tagging is homogeneous worldwide as far as possible to allow easy reuse of data. I've been asked too about "all maritime boundaries of the world"... I tried to extract that but it was too inconsistent to be useable. 2013/10/3 Martin Koppenhoefer > > > > Am 02/ott/2013 um 23:52 schrieb Christian Quest >: > > > > UK level 4 is on the maritime borders (island culture ?) where most > other European countries stop on the coastline... tagging bio-diversity is > not helpful ! > > > well, maybe this is how things are correct? years ago I stumbled upon > Liberia having a 200NM maritime border. Checking with other sources it > turned out that they indeed claim this area. Looking now at the osm map > someone has "normalized" the coastline leaving them the same maritime > border than the rest, and it looks "better" but I'm not sure it also is > more correct. > > The world is divers and the map should represent how things are, even if > this seems more chaotic than nicely structured. > > cheers, > Martin > > -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Administrative boundaries export
> Am 02/ott/2013 um 23:52 schrieb Christian Quest : > > UK level 4 is on the maritime borders (island culture ?) where most other > European countries stop on the coastline... tagging bio-diversity is not > helpful ! well, maybe this is how things are correct? years ago I stumbled upon Liberia having a 200NM maritime border. Checking with other sources it turned out that they indeed claim this area. Looking now at the osm map someone has "normalized" the coastline leaving them the same maritime border than the rest, and it looks "better" but I'm not sure it also is more correct. The world is divers and the map should represent how things are, even if this seems more chaotic than nicely structured. cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Administrative boundaries export
On Thu, Oct 3, 2013 at 6:52 AM, Christian Quest wrote: > UK level 4 is on the maritime borders (island culture ?) where most other > European countries stop on the coastline... tagging bio-diversity is not > helpful ! > This is actually another point to consider when extracting admin boundaries from OSM data. My personal view is that the admin boundary marks the boundary where the administrative entity exercises jurisdiction. Under UNCLOS, nations are allowed to exercise full sovereignty over internal waters (which includes water seaward of the coastline but within the baselines) and almost full sovereignty (foreign ships are allowed "innocent passage") for territorial waters (up to 12 nautical miles from the baselines). So I think that using the maritime boundaries as the admin_level=2 boundary is not incorrect and this is reflected in OSM. Use of maritime boundaries for admin_level=3 and higher (such as with UK) depends on how the particular nation interprets its internal maritime/fisheries laws. In my country, we have "municipal waters" which can be up to 15 kilometers from the shoreline and that's where municipalities can exercise jurisdiction. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Administrative boundaries export
Frederik explained many of the usual troubles you may encounter. Sorry to had many a few more :( I recently had to deal with admin boundaries and the lack of homogeneous tagging of worldwide reference numbers (like iso3166 or FIPS) does not help. For example US states had only the usual 2 letters in the ref=* tag, no fips code (which is a US federal classification) nor iso3166... so I added fips codes to US states. We could already start by making sure these worldwide references are present in OSM data, and do some QA on them (make sure none is missing, valid polygons, etc). To help you, have a look at http://layers.openstreetmap.fr/ which renders admin_level from 2 to 10... See for example level 4 in Europe: http://layers.openstreetmap.fr/?zoom=6&lat=48.21736&lon=2.70236&layers=0B000T UK level 4 is on the maritime borders (island culture ?) where most other European countries stop on the coastline... tagging bio-diversity is not helpful ! 2013/10/2 César Martínez Izquierdo > Hi, > > I plan to create and make easily available a world-wide administrative > layer based on OSM data, ideally including existing administrative codes > (ISO, NUTS in Europe, etc) for each level and producing regular updates > (for instance once a year). > > I think such a layer would be very useful for a number of scenarios, for > instance for scientific analysis involving administrative boundaries, > specially in areas where such data is not publicly available. Moreover, it > would probably attract collaborators to complete or correct the OSM > boundaries where needed. > > I'd like to learn about similar initiatives (I don't want to replicate > efforts) or interested people, and also about existing tools for > simplifying the work. My first idea is to use Map-it scripts (which create > KML Admin Boundaries files from OSM data) as a basis for this work, but > other ideas are welcome. > > Thanks in advance, > > César Martínez Izquierdo > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >César Martínez Izquierdo >GIS developer >- - - - - - - - - - - - - - - - - - - - >ETC-SIA: http://sia.eionet.europa.eu/ >Universitat Autònoma de Barcelona (SPAIN) > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > > -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Administrative boundaries export
The American Red Cross is dealing with this issue right now. We've built a database using GADM, GAUL, and Natural Earth. We initially wanted to rely heavily on OSM but because the relation breaks said it proved problematic. We've parked the use of OSM in our boundary dataset so that we can move forward with our implementation. We would love to help build out a plausible solution if one can be developed. The basic features of our current in production solution: - Name based lookup for anything in GADM, GAUL, Natural Earth, and GeoNames. - Ability to get the "admin stack", all admin boundaries above the currently selected feature, geoname, or WKT. - Ability to look at all of the datasets through time to use GADM. - Ability to get any feature from any of the datasets in geoJSON format. Our roadmap includes an API link to Nominatim and using the OSM polygon boundaries to then parse against our internal system to get the "admin stack" names and then going back to Nominatim to get the OSM geometry for the given features. Not the most elegant solution but I think it should work for most of our work where we want to use OSM admin boundaries. The code for our project is available on our github page. https://github.com/AmericanRedCross/GeoWebServices and https://github.com/AmericanRedCross/GeoDB. On Wed, Oct 2, 2013 at 4:01 PM, Eugene Alvin Villar wrote: > On Thu, Oct 3, 2013 at 3:58 AM, Frederik Ramm wrote: > >> What we would really need though, is something much bigger: A separate >> database of admin hierarchies, where people could - in a crowdsourced >> manner - record things like: >> >> "There is an adminlevel 2 entities called Germany" >> "It is divided into 16 exclusive adminlevel 4 entities with the >> following names: ..." >> "These 16 entities cover the area of Germany completely (no holes or sea >> areas that would be outside of one of the entities)" >> "The adminlevel 4 entity named 'Brandenburg' is divided in X adminlevel >> 6 entities..." >> >> and so on. A tree of arbitrary size where people can add and edit at will. >> > > This seems exactly like the kind of data I expect Wikidata (a Wikimedia > Foundation project, spearheaded by Wikimedia Deutschland) to encode. > > >> Now you will say "but this tree could be generated from OpenStreetMap", >> and I grant that one could attempt to build such a tree but it will >> always be faulty and reflect the current brokenness of geometries in >> OSM. One could *start* with an OSM-generated tree, but after that, the >> tree must be kept separate. People should be able to add stuff to the >> tree even when it is not in OpenStreetMap - "there should be an >> adminlevel 8 boundary called so-and-so". A regularly-running process >> > would then compare the tree to OpenStreetMap, and generate error reports >> that can be presented visually: [...] >> >> >> I would expect the tree to be much more stable than the >> data in OSM. Most of all, the tree could be worked on independently, >> even by people unfamiliar with OSM. Of course the tree could link to OSM >> objects but these links would regularly be checked and perhaps even >> changed by the automated comparison system. >> > > If this tree database will only be compared to OSM then it should be OK to > start it as a derivative of the OSM database (inheriting the ODbL license). > However, we lose the ability to compare this with other similar databases > like the Global Administrative Areas database (http://www.gadm.org/) as > another form of QA due to the license incompatibility. > > I think it would be better if the tree were started in Wikidata (which is > CC0-licensed) or as a separate project released to the public domain or > CC0- or PDDL-licensed. > > Eugene > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > > -- sent from my mobile device Dale Kunce http://normalhabit.com ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Administrative boundaries export
On Thu, Oct 3, 2013 at 3:58 AM, Frederik Ramm wrote: > What we would really need though, is something much bigger: A separate > database of admin hierarchies, where people could - in a crowdsourced > manner - record things like: > > "There is an adminlevel 2 entities called Germany" > "It is divided into 16 exclusive adminlevel 4 entities with the > following names: ..." > "These 16 entities cover the area of Germany completely (no holes or sea > areas that would be outside of one of the entities)" > "The adminlevel 4 entity named 'Brandenburg' is divided in X adminlevel > 6 entities..." > > and so on. A tree of arbitrary size where people can add and edit at will. > This seems exactly like the kind of data I expect Wikidata (a Wikimedia Foundation project, spearheaded by Wikimedia Deutschland) to encode. > Now you will say "but this tree could be generated from OpenStreetMap", > and I grant that one could attempt to build such a tree but it will > always be faulty and reflect the current brokenness of geometries in > OSM. One could *start* with an OSM-generated tree, but after that, the > tree must be kept separate. People should be able to add stuff to the > tree even when it is not in OpenStreetMap - "there should be an > adminlevel 8 boundary called so-and-so". A regularly-running process > would then compare the tree to OpenStreetMap, and generate error reports > that can be presented visually: [...] > > I would expect the tree to be much more stable than the > data in OSM. Most of all, the tree could be worked on independently, > even by people unfamiliar with OSM. Of course the tree could link to OSM > objects but these links would regularly be checked and perhaps even > changed by the automated comparison system. > If this tree database will only be compared to OSM then it should be OK to start it as a derivative of the OSM database (inheriting the ODbL license). However, we lose the ability to compare this with other similar databases like the Global Administrative Areas database (http://www.gadm.org/) as another form of QA due to the license incompatibility. I think it would be better if the tree were started in Wikidata (which is CC0-licensed) or as a separate project released to the public domain or CC0- or PDDL-licensed. Eugene ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Administrative boundaries export
Hi,
On 02.10.2013 18:23, César Martínez Izquierdo wrote:
> I plan to create and make easily available a world-wide administrative
> layer based on OSM data, ideally including existing administrative codes
> (ISO, NUTS in Europe, etc) for each level and producing regular updates
> (for instance once a year).
This is something I have been thinking about for a long time (but never
written any usable code).
Nominatim is probably a good starting point - a better one than MapIt I
should think.
If you're only after extracting certain relation polygons then you could
as well use osmjs (part of Osmium) and have it generate shape files for
you, or adapt the shapefile/ogr export samples in Osmium; this will not
yet give you a hierarchy, only individual boundaries, and you have to
find out the hierarchy yourself.
Finding out the hierarchy is going to be tricky. Nominatim does go to
some lengths to do that already. It sounds easy ("find all polygons with
an admin level smaller than X where this polygon I'm looking at lies
in"). But in reality you will encounter at least:
* missing polygons on all levels - sometimes simply not mapped,
sometimes missing by design, e.g. Germany has some areas where admin
levels 8, 6, and 4 coincide, these are mapped as admin_level 4, so draw
a map of all admin_level 8 areas in Germany and you have lots of holes
in them
* broken polygons on all levels; brokenness changes by the day, i.e.
what is working today may be broken tomorrow and vice versa
* occasionally (e.g. Japan) linear regional boundaries that simply go
from coast to coast without including the coastline
* occasionally (e.g. Chile) a regional boundary that is not a
multipolygon relation but instead a grouping of smaller regional entities
* sometimes small geometric inaccuracies mean that e.g. a state boundary
fails the "is-in" test for the country boundary because there's just a
little square metre somewhere that is mapped as belonging to the state
but not the country
* overlapping admin polygons of the same admin level
I think that ate the very least you need to run the evaluation regularly
and compare: Do I have new polygons this week - have others vanished,
and if so, is that because they were explicitly deleted/replaced, or
were they just accidentally broken and I should continue to use last week's?
What we would really need though, is something much bigger: A separate
database of admin hierarchies, where people could - in a crowdsourced
manner - record things like:
"There is an adminlevel 2 entities called Germany"
"It is divided into 16 exclusive adminlevel 4 entities with the
following names: ..."
"These 16 entities cover the area of Germany completely (no holes or sea
areas that would be outside of one of the entities)"
"The adminlevel 4 entity named 'Brandenburg' is divided in X adminlevel
6 entities..."
and so on. A tree of arbitrary size where people can add and edit at will.
Now you will say "but this tree could be generated from OpenStreetMap",
and I grant that one could attempt to build such a tree but it will
always be faulty and reflect the current brokenness of geometries in
OSM. One could *start* with an OSM-generated tree, but after that, the
tree must be kept separate. People should be able to add stuff to the
tree even when it is not in OpenStreetMap - "there should be an
adminlevel 8 boundary called so-and-so". A regularly-running process
would then compare the tree to OpenStreetMap, and generate error reports
that can be presented visually:
"The tree says that there should be a region called X in Germany but OSM
doesn't have one."
"There is an area here that is not covered by any adminlevel 4 area but
the tree says that taken together the adminlevel 4 areas must cover all
of the country."
"The tree claims there should be a region called X but in OSM there's
only a region with the similar name Y, which one is correct?"
and so on. - I would expect the tree to be much more stable than the
data in OSM. Most of all, the tree could be worked on independently,
even by people unfamiliar with OSM. Of course the tree could link to OSM
objects but these links would regularly be checked and perhaps even
changed by the automated comparison system.
As I said, a simple export is easy but it will have too many weaknesses
- you couldn't even say to what level a country is "complete". Some
people have started to link regional boundaries in OSM together with
concepts like "subarea" but I don't think this can replace an external
country structure tree because the tree could describe what is expected
to be there whereas in OSM you never know if some thing is missing
because it doesn't exist (cf. my example about the "missing" admin6/8
boundaries in Germany) or if it just hasn't been mapped yet, or is broken.
It would be great to see someone drive this important topic but it
certainly isn't something you can set up in a week or two ;)
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N4
Re: [OSM-talk] Administrative boundaries export
On Wed, Oct 2, 2013 at 6:23 PM, César Martínez Izquierdo wrote: > I plan to create and make easily available a world-wide administrative layer > based on OSM data, ideally including existing administrative codes (ISO, > NUTS in Europe, etc) for each level and producing regular updates (for > instance once a year). thanks for jumping on this. I think this is a much needed export. some thoughts: 1. admin data is stored with relations, which is not that easy to maintain. you WILL always find broken borders. 2. having a web app to visualize that, and allow people to fix them is something needed. similar to what we already have for the coastline. 3. once a year might be too much time between releases, think about a once a year "stable" release, where all borders compile correctly. 4. show stats on broken, fixed borders. 5. provide them as a download in shapefile, poly format, geojson, and kml. Thanks, Simone. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Administrative boundaries export
Hi, I plan to create and make easily available a world-wide administrative layer based on OSM data, ideally including existing administrative codes (ISO, NUTS in Europe, etc) for each level and producing regular updates (for instance once a year). I think such a layer would be very useful for a number of scenarios, for instance for scientific analysis involving administrative boundaries, specially in areas where such data is not publicly available. Moreover, it would probably attract collaborators to complete or correct the OSM boundaries where needed. I'd like to learn about similar initiatives (I don't want to replicate efforts) or interested people, and also about existing tools for simplifying the work. My first idea is to use Map-it scripts (which create KML Admin Boundaries files from OSM data) as a basis for this work, but other ideas are welcome. Thanks in advance, César Martínez Izquierdo -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - César Martínez Izquierdo GIS developer - - - - - - - - - - - - - - - - - - - - ETC-SIA: http://sia.eionet.europa.eu/ Universitat Autònoma de Barcelona (SPAIN) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
