[OSM-dev] (Multi)Polygon handling

[Peter Wendorff]

Am 13.07.2012 10:13, schrieb Paul Norman:
>> From: nimix [mailto:melchiormoos at gmail.com]
>> Sent: Friday, July 13, 2012 12:58 AM
>> To: dev at openstreetmap.org
>> Subject: [OSM-dev] (Multi)Polygon handling
>>
>>
>> Frederik Ramm wrote
>>>
>>> If we can't get everyone to use the same code base, then it would at
>>> least be great to reach some kind of agreement here, or maybe at least
>>> produce a test suite that everyone runs their code against.
>>>
>>>
>> I created a testsuite for that with some more cases that need special
>> treatment. Unfortunately I only stored the WKB representation in Google
>> mercator projection, so it is not very human readable. The testcase
>> contains a LINESTRING and a MULTIPOLYGON for simple closed ways and for
>> relations a MULTILINESTRING and a MULTIPOLYGON ([1]).
>>
>> I would volunteer to bring it in an other format so that it is useful
>> for everyone writing converters and I would like to discuss what is the
>> best way to do it. I would suggest an .osm file and a Wiki Page
>> containing the expected results in WKT/WKB and some explanation for each
>> case. Any other ideas?
>> Best regards,
>> Melchior
> My following of web standards has convinced me it is necessary to define the
> expected output in every case, including invalid ones, or you will have
> differing implementations. I've been giving it some thought as to what needs
> to be tested, and I don't think it's excessive. I'd estimate 25-50 small
> tests would cover everything.
+1
But it should be possible to reject false polygon models.
So to say:
- any application "must" deal with correct tagging in the same way 
(which is defined by the corresponding test cases)
- if an application interprets wrong polygons, it "must" do it in the 
way which is defined by the corresponding test cases
- but(!) every application is allowed to reject these polygons because 
of errors
- any application is encouraged to report wrong polygons detected to 
users who may be able to fix that in the database.

("must" of course only to correctly claim "standard" osm polygon handling)

regards
Peter