[OSM-talk] Administrative boundaries export

[Dale Kunce]

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 <seav80 at gmail.com>wrote:

> On Thu, Oct 3, 2013 at 3:58 AM, Frederik Ramm <frederik at remote.org> 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>


-- 
sent from my mobile device

Dale Kunce
http://normalhabit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20131002/a14ba35d/attachment-0001.html>