How to split polygons into boundary relations with common ways?

This is somewhat off-topic for mkgmap, but I was thinking that perhaps WanMil or someone else has worked on something similar. I got some boundary data. I converted a tiny part of it from Spatialite to *.osm polygons with a self-made Perl script. There were some errors in the data, such as nodes very close to each other, or some boundary had one point less than the adjacent boundary. I fixed these in JOSM, by merging the too close nodes, or adding the missing nodes to boundaries. Already this was a considerable amount of work, because JOSM seems to lack a validator test for "nodes too close to each other" when they belong to different ways. Now, the next step would be to split these polygons (circular ways) to boundary relations. Each polygon would have to be split to way segments, and duplicate way segments should be removed. Then, relations should be formed from the way segments for each area. Is there any software or algorithm for doing this? Best regards, Marko

Don't know any software for osm files. But if you could create shape files first then there are 1 or 2 converters from shape to osm format which can create the relations and remove duplicate ways. On Jan 24, 2012, at 4:55 AM, Marko Mäkelä wrote:
This is somewhat off-topic for mkgmap, but I was thinking that perhaps WanMil or someone else has worked on something similar.
I got some boundary data. I converted a tiny part of it from Spatialite to *.osm polygons with a self-made Perl script. There were some errors in the data, such as nodes very close to each other, or some boundary had one point less than the adjacent boundary. I fixed these in JOSM, by merging the too close nodes, or adding the missing nodes to boundaries. Already this was a considerable amount of work, because JOSM seems to lack a validator test for "nodes too close to each other" when they belong to different ways.
Now, the next step would be to split these polygons (circular ways) to boundary relations. Each polygon would have to be split to way segments, and duplicate way segments should be removed. Then, relations should be formed from the way segments for each area. Is there any software or algorithm for doing this?
Best regards,
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

On Tue, Jan 24, 2012 at 07:58:21AM -0800, Apollinaris Schoell wrote:
Don't know any software for osm files. But if you could create shape files first then there are 1 or 2 converters from shape to osm format which can create the relations and remove duplicate ways.
Right, ogr2osm should be one of them. I guess I will have to go back from osm to shape format and then try my luck with these converters. Do you know if there is any shape file converter that would merge nearby nodes to a single OSM node id? In this data set, adjacent areas sometimes have nodes in almost the same position. This should be a problem in the original dataset and not a coordinate transformation artefact, because a transformation could map multiple points to one point, but not vice versa. Marko

On Jan 24, 2012, at 1:58 PM, Marko Mäkelä wrote:
On Tue, Jan 24, 2012 at 07:58:21AM -0800, Apollinaris Schoell wrote:
Don't know any software for osm files. But if you could create shape files first then there are 1 or 2 converters from shape to osm format which can create the relations and remove duplicate ways.
Right, ogr2osm should be one of them. I guess I will have to go back from osm to shape format and then try my luck with these converters.
Do you know if there is any shape file converter that would merge nearby nodes to a single OSM node id? In this data set, adjacent areas sometimes have nodes in almost the same position. This should be a problem in the original dataset and not a coordinate transformation artefact, because a transformation could map multiple points to one point, but not vice versa.
never found any good solution for merging points or simplify except Josm
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

On Tue, Jan 24, 2012 at 02:27:24PM -0800, Apollinaris Schoell wrote:
Right, ogr2osm should be one of them. I guess I will have to go back from osm to shape format and then try my luck with these converters.
osm2shp was good enough for my needs. I liked the simple configuration by editing some C functions. Then, ogr2osm processed the shape file.
Do you know if there is any shape file converter that would merge nearby nodes to a single OSM node id? In this data set, adjacent areas sometimes have nodes in almost the same position. This should be a problem in the original dataset and not a coordinate transformation artefact, because a transformation could map multiple points to one point, but not vice versa.
never found any good solution for merging points or simplify except Josm
I played with JOSM Validator. It did detect some (but not all) problems when I deleted the boundary relations and set highway=service on all lines. There might be some solution outside the OSM domain. The thread starter is the guy who converted the data set that I am processing: http://thread.gmane.org/gmane.comp.gis.jump.devel/10457 Hopefully, this solution will help the import of other suburb boundaries. I am testing with the suburbs of my home town only. Best regards, Marko
participants (2)
-
Apollinaris Schoell
-
Marko Mäkelä