Sorry about missing the list<br><br><div class="gmail_quote"><div class="gmail_quote"><span dir="ltr"></span><div class="im"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Hi all,<br>
<br>
<br>
During the imports support group conference call, the question of import tools<br>
was raised.<br>
<br>
I can't quite recall everyone's point of view, but I think that the general<br>
idea was "the more tools, the better".<br>
<br>
I'm all for an unix-like approach: lots of small specialised tools, that work<br>
together in order to do an import. Right now we got conversors, filters,<br>
uploaders and whatnot.<br>
<br>
<br>
But one thing I'm missing is a "polygon relationificator". Let me explain.<br>
<br>
<br>
Let's suppose I've got a shapefile/GML/spatialite file full of polygons; and<br>
such polygons do not overlap each other, and are adjacent to each other to<br>
cover a large area. Think land use and administrative areas.<br>
<br>
And, as defined in <a href="http://wiki.osm.org/wiki/Multipolygon" target="_blank">http://wiki.osm.org/wiki/Multipolygon</a> , we can have<br>
multipolygons with several outer ways - which will be joined together when<br>
exporting to another format (e.g. osm2pgsql).<br>
<br>
<br>
You can see where this goes. If the input polygons are non-overlapping and<br>
adjacent, I could redraw the edges of the polygons as graph edges, put a<br>
graph node whenever three (or more) polygons touch each other, and then apply<br>
some graph theory to convert every polygon to a set of graph edges ( =<br>
relation of ways = multipolygon with several outer ways )<br>
<br>
IMHO, this would be good not only for data imports, but also for integrity<br>
checks (detect overlaps) and cleanup, given OSM input and OSM output.<br>
<br>
<br>
<br>
Question is:<br>
<br>
Is such a tool available? If not, who has interest in making such tool?<br>
<br></blockquote></div></div><br>I am not sure that I understand everything you are saying, but here is some explanation of what I have been doing.<br>Well, I have modified polyshp2osm.py to create that kind of polygons. It will cut any ways larger than 2000 nodes. We have some cases in Corine where we have multiple outer ways.<br>

The integrity checks and overlaps are performed by Postgis. Currently, the code does the following things:<br>Database -> SHP -> OSM<br>The first step is based is using the postgres2shp tool provided with postgis. The next step is done by polyshp2osm (based on GDAL). I am currently looking at modifying polyshp2osm to read directly from the database, as it would be useful for the polygons not merged as a tool. Also, another contributor created a program that is merging nodes inside the OSM file to consolidate everything. It helps reducing the size of the files in our case.<br>

<br>I am finishing an email explaining how we are proceeding on our imports with the Corine database. It will come in the next days. After getting people to check data on a test database, we realized that the overlap detection was not working as efficiently as we wanted (We get 98% of them right), so we are adding special cases to perform a clean import to minimize the risks on contributors.<br>

<br>I believe landuse polygons are the easiest to deal with in the first place. It is much easier to deal with them than with roads.I hope it makes sense.<br><br>This page is old, and not completely accurate any more but it is giving an idea of how the logic is working:<br>

<a href="http://wiki.openstreetmap.org/wiki/WikiProject_Corine_Land_Cover/Corine_Data_Import" target="_blank">http://wiki.openstreetmap.org/wiki/WikiProject_Corine_Land_Cover/Corine_Data_Import</a><br><font color="#888888"><br>
Emilie Laffray<br>
</font></div><br>