[Imports] Fwd: Polygon relationificator

[Emilie Laffray]

Sorry about missing the list


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

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.

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.

This page is old, and not completely accurate any more but it is giving an
idea of how the logic is working:
http://wiki.openstreetmap.org/wiki/WikiProject_Corine_Land_Cover/Corine_Data_Import

Emilie Laffray
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20090914/fa1ae42e/attachment.html>