Hi
Am 13.07.2012 14:41, schrieb nimix:
[1] https://github.com/nimix/osm_conv_tests
good start but I'd remove the .wkb files in favor of the wkt ones. You
shouldn't have two versions of the expected output or you will get cases
where the WKB and WKT differs. And it's unclear what the real
Peter Körner wrote
good start but I'd remove the .wkb files in favor of the wkt ones. You
shouldn't have two versions of the expected output or you will get cases
where the WKB and WKT differs. And it's unclear what the real expected
result is.
At the moment the .wkt and the .wkb
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
From: nimix [mailto:melchiorm...@gmail.com]
Sent: Friday, July 13, 2012 12:58 AM
To: dev@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
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.
From: Jochen Topf [mailto:joc...@remote.org]
Cc: dev@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
Jochen123 wrote
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.
I thought about focusing on geometry first since this
Hi,
On 07/13/2012 12:17 PM, nimix wrote:
I thought about focusing on geometry first since this is the more
complicated part. But sure for tags it gets very complicated if we consider
diff files too.
Tags are complicated enough without diffs.
Scenario 1: Untagged multipolygon relation, outer
I did a first commit on github containing a testsuite for invalid geometries
formed by closed ways and their expected repaired version [1]. If you are
happy with the format, I would continue with the invalid multipolygons...
I would suggest to have the tag tests in a different test suite (a new
Am 13.07.2012 10:13, schrieb Paul Norman:
From: nimix [mailto:melchiorm...@gmail.com]
Sent: Friday, July 13, 2012 12:58 AM
To: dev@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
On Fri, Jul 13, 2012 at 03:24:47PM +0200, Even Rouault wrote:
That sounds reasonable. But we need to agree on what is valid and what is
treated as invalid. In the testsuite of closed ways that I commited to
github I defined an output for every case, but I'm not sure if the inputs
are
On Fri, Jul 13, 2012 at 03:24:47PM +0200, Even Rouault wrote:
3-5 not sure
6) invalid
7) valid
8) not sure
9) invalid
10) valid
11,12) invalid
I think I disagree with all those ones ;-) For me, a way is a LINESTRING or a
POLYGON with a single ring. I'd take it unmodified. And if
On 13/07/2012 16:05, Jochen Topf wrote:
On Fri, Jul 13, 2012 at 03:24:47PM +0200, Even Rouault wrote:
That sounds reasonable. But we need to agree on what is valid and what is
treated as invalid. In the testsuite of closed ways that I commited to
github I defined an output for every case, but
Hi,
On 13.07.2012, at 15:24, Even Rouault wrote:
My perception was that the only part that need some thinking is when building
a
MULTIPOLYGON from multiple ways referenced by a relation ( bascially what is
described in http://wiki.openstreetmap.org/wiki/Relation:multipolygon ). But
I'm
Even Rouault wrote
2) valid
Why do you need to reverse the winding order ? I thought that the WKT
convention
did not say anything about that, or did I miss something ? (Winding order
is
indeed significant in shapefiles, but that's another story). So I'd say it
is up
to the rendering
Hi,
On 07/13/2012 04:59 PM, nimix wrote:
If I remember it right mapnik requires normalized geometries, so outer in
clockwise and inners in counterclockwise order. I'm not sure if that is
still the case, but osm2pgsql still does the normalization. That's why I
defined the result in clockwise
From: Jochen Topf [mailto:joc...@remote.org]
Sent: Friday, July 13, 2012 5:02 AM
To: Paul Norman
Cc: 'nimix'; dev@openstreetmap.org
Subject: Re: [OSM-dev] (Multi)Polygon handling
On Fri, Jul 13, 2012 at 03:11:40AM -0700, Paul Norman wrote:
For a lot of the invalid cases there won't
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
Frederik Ramm wrote
On 07/13/2012 04:59 PM, nimix wrote:
If I remember it right mapnik requires normalized geometries, so outer in
clockwise and inners in counterclockwise order. I'm not sure if that is
still the case, but osm2pgsql still does the normalization. That's why I
defined the
I don't know if that is an ESRI curiosity or following the standard, and
if so, what standard. If it should turn out to be a convention for shape
files but not for Simple Features generally, then any program that
creates shape files should fix the winding order.
I've found the following
Am 13.07.2012 18:31, schrieb nimix:
Hi, I just has a look at this... Mapnik indeed has no such requirement. But
it requires inner rings of multipolygons do be in a different orientation
than the outer ring. Hence it is reasonable to ensure that by just making
all outers cw and inners ccw.
That
On Fri, Jul 13, 2012 at 08:12:34AM -0700, Paul Norman wrote:
From: Jochen Topf [mailto:joc...@remote.org]
Sent: Friday, July 13, 2012 5:02 AM
To: Paul Norman
Cc: 'nimix'; dev@openstreetmap.org
Subject: Re: [OSM-dev] (Multi)Polygon handling
On Fri, Jul 13, 2012 at 03:11:40AM -0700
On Fri, Jul 13, 2012 at 04:22:24PM +0200, Colin Smale wrote:
On 13/07/2012 16:05, Jochen Topf wrote:
On Fri, Jul 13, 2012 at 03:24:47PM +0200, Even Rouault wrote:
That sounds reasonable. But we need to agree on what is valid and what is
treated as invalid. In the testsuite of closed ways that
On Fri, Jul 13, 2012 at 07:53:30PM +0200, Peter Wendorff wrote:
Am 13.07.2012 18:31, schrieb nimix:
Hi, I just has a look at this... Mapnik indeed has no such requirement. But
it requires inner rings of multipolygons do be in a different orientation
than the outer ring. Hence it is reasonable
24 matches
Mail list logo
