[OSM-dev] (Multi)Polygon handling

nimix melchiormoos at gmail.com
Fri Jul 13 16:57:35 BST 2012


Jochen123 wrote
> 
> 
> I think I agree with your here. Whether a simple polygon is valid or not
> that
> tells us the Simple feature definition. Software that turns single ways
> into
> single polygons should only look at one thing: If the way is closed, it is
> porentially a polygon and can be converted to one. The conversion is
> straightforward and easy. The software is not supposed to fix ways that
> might
> result in invalid polygons. The result is a Simple Feature polygon and if
> some application wants to check whether a polygon is valid, it can do so.
> If it is valid, the way was valid, if not, then not.
> 
> The case for multipolygons is different. Here there are several ways and a
> relation involved. It is much more difficult to assemble the raw data into
> a multipolygon. What we want to agree on is how exactly this assembling is
> done. It might be if you follow the assembling process exactly the result
> is an invalid multipolygon. Thats okay.
> 
> We are not trying to make sure there aren't any invalid geometries
> generated.
> We are trying to make sure we agree on the result of the conversion
> process,
> may it be a valid (multi)polygon or an invalid one.
> 
> 

Ok so, we can agree that in the closed way testsuite everything except 1,2
is invalid. I added .result files indicating that to the repository.

But I don't like the idea to define the expected output to invalid
geometries. There should be either a reasonable result or nothing. Otherwise
it is impossible to have a repairing algorithm passing the test...

Just a minute ago a also added a testcase for geometry output of
multipolygons. Again we need to discuss which cases are valid and which are
not. So far my opinion is:
1-3, 6-8 valid
4-5, 9-10 invalid

Again for those not willing to look into github. I am talking about
multipolygons in [1] from bottom to top.

[1] https://dl.dropbox.com/u/58628/multipolygontest.osm

Regards,
Melchior



--
View this message in context: http://gis.19327.n5.nabble.com/New-OGR-driver-to-read-OpenStreetMap-osm-pbf-files-tp5715906p5716524.html
Sent from the Developer Discussion mailing list archive at Nabble.com.



More information about the dev mailing list