[OSM-dev] (Multi)Polygon handling

Paul Norman penorman at mac.com
Fri Jul 13 11:11:40 BST 2012

> From: Jochen Topf [mailto:jochen at remote.org]
> Cc: dev at openstreetmap.org
> Subject: Re: [OSM-dev] (Multi)Polygon handling
> On Fri, Jul 13, 2012 at 12:57:33AM -0700, nimix wrote:
> > 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?
> Just the geometries is not enough. We also need the tags in some form,
> because part of the multipolygon assembly is deciding which tags from
> the relation and which tags from the member ways make it to the output.
> Input as .osm is good. But the output should not be on a wiki page but
> in some format so that it can be used for automated checks. I think the
> whole thing should probably be in a git repository.
> Maybe a subdirectory for each test case which contains the .osm input
> file, a .wkt output file, a .tags output file and a .result output file
> or so that has information whether the test should succeed or fail.
> Maybe other files, too with more detailed information if that turns out
> to be needed. Plus a README in every directory describing the test case
> to the developer.

For a lot of the invalid cases there won't be a defined output yet. To some
extent osm2pgsql is a reference but I have no clue what it would do in some
of the possible combinations of invalid tagging and invalid geometry

More information about the dev mailing list