<div dir="ltr"><div><div><div>That sounds interesting. I am not familiar with Nominatim, but I have correctly understood, the result is a Postgres/postgis database with all those polygons and hierarchies. This could be an interesting approach as the post-processing could be directly done there using PostGIS predicates.<br>
<br></div>However, I am not sure about the generated hierarchies, as they don't keep all OSM admin_levels into account (at least in the nomenclature: country, state, county) and I see clear errors for Spain using the link [2] that you provided. It would be interesting to know how these hierarchies are generated (just OSM tags and geometric relations, external database, etc).<br>
<br></div>In any case, it seems a good starting point for my project.<br></div><div><br></div><div>Cheers,<br></div><div><br></div>Cesar<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/10/3 Sarah Hoffmann <span dir="ltr"><<a href="mailto:lonvia@denofr.de" target="_blank">lonvia@denofr.de</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thu, Oct 03, 2013 at 12:32:36PM +0200, César Martínez Izquierdo wrote:<br>
> Hi Frederik, regarding software, I am already familiar with Mapit scripts<br>
> code, which are able to extract admin boundary polygons for each level (it<br>
> is not creating relationships though). How do you see Nominatim or<br>
> Osmium/osmjs better for the purpose?<br>
<br>
</div>Nominatim already does a lot of the stuff you are planning to do. It<br>
creates geometries for admin boundaries from OSM data and puts them<br>
in a proper hierarchy. It is able to process updates and in the<br>
process makes sure that boundaries do not just disappear if somebody<br>
breaks the relation. If you only process the data that interests you (boundary=administrative and place nodes) it is not even that<br>
resource-hungry.<br>
<br>
It does have support for listing broken boundaries [1] and during the<br>
last hack day Brian has written a proof-of-concept for browsing admin<br>
hierarchies[2]. There is even a script to dump objects within a certain<br>
boundary[3] which could be easily extended to dump entire hierarchies.<br>
All these functions should currently be used with care though. There are<br>
known bugs and the output needs to be improved to make them really<br>
usable.<br>
<br>
Basically, most of the work to do would be on the output side, the<br>
heavy lifting of processing the data is already done. Well, apart<br>
from checking the OSM boundaries against reality. But I think wiki data<br>
is a good starting point for that.<br>
<div class="im"><br>
> I will probably try the first option, but I expect that any of them would<br>
> be costly to maintain if there are frequent changes of the tagging scheme<br>
> for each country. (But nobody said it would be an easy task :-)<br>
<br>
</div>Making boundary tagging more visible will hopefully help to stablize<br>
and unify the tagging schemas. The less country-specific exceptions<br>
the better.<br>
<br>
Sarah<br>
<br>
[1] <a href="http://nominatim.osm.org/polygons" target="_blank">http://nominatim.osm.org/polygons</a><br>
[2] <a href="http://nominatim.openstreetmap.org/hierarchy.php?place_id=97944985" target="_blank">http://nominatim.openstreetmap.org/hierarchy.php?place_id=97944985</a><br>
    (This is for demonstration only, please do not scrape. It will not<br>
                always give you the expected results anyways because there is a<br>
                known bug with parenting which still lingers in the DB.)<br>
[3] <a href="https://github.com/lonvia/Nominatim/blob/export-script/utils/export.php" target="_blank">https://github.com/lonvia/Nominatim/blob/export-script/utils/export.php</a><br>
<div class="HOEnZb"><div class="h5"><br>
> 2013/10/2 Frederik Ramm <<a href="mailto:frederik@remote.org">frederik@remote.org</a>><br>
><br>
> > Hi,<br>
> ><br>
> > On 02.10.2013 18:23, César Martínez Izquierdo wrote:<br>
> > > I plan to create and make easily available a world-wide administrative<br>
> > > layer based on OSM data, ideally including existing administrative codes<br>
> > > (ISO, NUTS in Europe, etc) for each level and producing regular updates<br>
> > > (for instance once a year).<br>
> ><br>
> > This is something I have been thinking about for a long time (but never<br>
> > written any usable code).<br>
> ><br>
> > Nominatim is probably a good starting point - a better one than MapIt I<br>
> > should think.<br>
> ><br>
> > If you're only after extracting certain relation polygons then you could<br>
> > as well use osmjs (part of Osmium) and have it generate shape files for<br>
> > you, or adapt the shapefile/ogr export samples in Osmium; this will not<br>
> > yet give you a hierarchy, only individual boundaries, and you have to<br>
> > find out the hierarchy yourself.<br>
> ><br>
> > Finding out the hierarchy is going to be tricky. Nominatim does go to<br>
> > some lengths to do that already. It sounds easy ("find all polygons with<br>
> > an admin level smaller than X where this polygon I'm looking at lies<br>
> > in"). But in reality you will encounter at least:<br>
> ><br>
> > * missing polygons on all levels - sometimes simply not mapped,<br>
> > sometimes missing by design, e.g. Germany has some areas where admin<br>
> > levels 8, 6, and 4 coincide, these are mapped as admin_level 4, so draw<br>
> > a map of all admin_level 8 areas in Germany and you have lots of holes<br>
> > in them<br>
> ><br>
> > * broken polygons on all levels; brokenness changes by the day, i.e.<br>
> > what is working today may be broken tomorrow and vice versa<br>
> ><br>
> > * occasionally (e.g. Japan) linear regional boundaries that simply go<br>
> > from coast to coast without including the coastline<br>
> ><br>
> > * occasionally (e.g. Chile) a regional boundary that is not a<br>
> > multipolygon relation but instead a grouping of smaller regional entities<br>
> ><br>
> > * sometimes small geometric inaccuracies mean that e.g. a state boundary<br>
> > fails the "is-in" test for the country boundary because there's just a<br>
> > little square metre somewhere that is mapped as belonging to the state<br>
> > but not the country<br>
> ><br>
> > * overlapping admin polygons of the same admin level<br>
> ><br>
> > I think that ate the very least you need to run the evaluation regularly<br>
> > and compare: Do I have new polygons this week - have others vanished,<br>
> > and if so, is that because they were explicitly deleted/replaced, or<br>
> > were they just accidentally broken and I should continue to use last<br>
> > week's?<br>
> ><br>
> > What we would really need though, is something much bigger: A separate<br>
> > database of admin hierarchies, where people could - in a crowdsourced<br>
> > manner - record things like:<br>
> ><br>
> > "There is an adminlevel 2 entities called Germany"<br>
> > "It is divided into 16 exclusive adminlevel 4 entities with the<br>
> > following names: ..."<br>
> > "These 16 entities cover the area of Germany completely (no holes or sea<br>
> > areas that would be outside of one of the entities)"<br>
> > "The adminlevel 4 entity named 'Brandenburg' is divided in X adminlevel<br>
> > 6 entities..."<br>
> ><br>
> > and so on. A tree of arbitrary size where people can add and edit at will.<br>
> ><br>
> > Now you will say "but this tree could be generated from OpenStreetMap",<br>
> > and I grant that one could attempt to build such a tree but it will<br>
> > always be faulty and reflect the current brokenness of geometries in<br>
> > OSM. One could *start* with an OSM-generated tree, but after that, the<br>
> > tree must be kept separate. People should be able to add stuff to the<br>
> > tree even when it is not in OpenStreetMap - "there should be an<br>
> > adminlevel 8 boundary called so-and-so". A regularly-running process<br>
> > would then compare the tree to OpenStreetMap, and generate error reports<br>
> > that can be presented visually:<br>
> ><br>
> > "The tree says that there should be a region called X in Germany but OSM<br>
> > doesn't have one."<br>
> ><br>
> > "There is an area here that is not covered by any adminlevel 4 area but<br>
> > the tree says that taken together the adminlevel 4 areas must cover all<br>
> > of the country."<br>
> ><br>
> > "The tree claims there should be a region called X but in OSM there's<br>
> > only a region with the similar name Y, which one is correct?"<br>
> ><br>
> > and so on. - I would expect the tree to be much more stable than the<br>
> > data in OSM. Most of all, the tree could be worked on independently,<br>
> > even by people unfamiliar with OSM. Of course the tree could link to OSM<br>
> > objects but these links would regularly be checked and perhaps even<br>
> > changed by the automated comparison system.<br>
> ><br>
> > As I said, a simple export is easy but it will have too many weaknesses<br>
> > - you couldn't even say to what level a country is "complete". Some<br>
> > people have started to link regional boundaries in OSM together with<br>
> > concepts like "subarea" but I don't think this can replace an external<br>
> > country structure tree because the tree could describe what is expected<br>
> > to be there whereas in OSM you never know if some thing is missing<br>
> > because it doesn't exist (cf. my example about the "missing" admin6/8<br>
> > boundaries in Germany) or if it just hasn't been mapped yet, or is broken.<br>
> ><br>
> > It would be great to see someone drive this important topic but it<br>
> > certainly isn't something you can set up in a week or two ;)<br>
> ><br>
> > Bye<br>
> > Frederik<br>
> ><br>
> > --<br>
> > Frederik Ramm  ##  eMail <a href="mailto:frederik@remote.org">frederik@remote.org</a>  ##  N49°00'09" E008°23'33"<br>
> ><br>
> > _______________________________________________<br>
> > talk mailing list<br>
> > <a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br>
> > <a href="https://lists.openstreetmap.org/listinfo/talk" target="_blank">https://lists.openstreetmap.org/listinfo/talk</a><br>
> ><br>
><br>
><br>
><br>
> --<br>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -<br>
>    César Martínez Izquierdo<br>
>    GIS developer<br>
>    -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -<br>
>    ETC-SIA: <a href="http://sia.eionet.europa.eu/" target="_blank">http://sia.eionet.europa.eu/</a><br>
>    Universitat Autònoma de Barcelona (SPAIN)<br>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -<br>
<br>
> _______________________________________________<br>
> talk mailing list<br>
> <a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br>
> <a href="https://lists.openstreetmap.org/listinfo/talk" target="_blank">https://lists.openstreetmap.org/listinfo/talk</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -<br>   César Martínez Izquierdo<br>   GIS developer<br>   -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -<br>
   ETC-SIA: <a href="http://sia.eionet.europa.eu/" target="_blank">http://sia.eionet.europa.eu/</a><br>   Universitat Autònoma de Barcelona (SPAIN)<br>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
</div>