cunit and sql failure on build area

[robe]

strk,

This is failing on my mingw32 chain. Do your build area changes rely on new GEOS changes. Haven't recompiled my GEOS 3.3.4dev (r3614) yet (and that is about a 2 weeks old I think).

Suite: buildarea
  Test: buildarea1 ... passed
  Test: buildarea2 ...  Failure at cu_buildarea.c:94
 Exp: POLYGON((0 0,0 10,10 10,20 10,20 0,10 0,0 0))
 Obt: POLYGON((10 10,20 10,20 0,10 0,0 0,0 10,10 10))
FAILED
    1. cu_buildarea.c:94  - 0

Haven't tested yet on my ming64 chain. This is r9732

[strk]

What about r9730 and r9731 ? (no, I wouldn't expect them to be different depending on GEOS)

Oh, or maybe if they do they also do in r9730, as I've added a short-circuit in GEOS-3.3.4SVN for the SymDifference case.

The problem here is we don't have "Equals" in liblwgeom, nor we have "Normalize". I guess we'll want to add a "normalize" function for then doing pointwise comparison.

[robe]

fails with the latest geos 3.3.4 dev as well. I also get the same failure on my ming64 chain.

r9730 on my ming64 chain looks even worse (haven't bothered testing on my mingw32). Did you take out some tests between r9730 and r9732?

This is the failures I get on ming64 on r9730: (though a lot do seem just like reorders of polygons so are equal)

Suite: buildarea
  Test: buildarea1 ... Failure at cu_buildarea.c:62
 Exp: MULTIPOLYGON(((0 0,0 10,10 10,10 0,0 0)),((10 10,10 20,20 20,20 10,10 10))
)
 Obt: MULTIPOLYGON(((10 10,10 20,20 20,20 10,10 10)),((0 0,0 10,10 10,10 0,0 0))
)
FAILED
    1. cu_buildarea.c:62  - 0
  Test: buildarea2 ... Failure at cu_buildarea.c:94
 Exp: POLYGON((0 0,0 10,10 10,20 10,20 0,10 0,0 0))
 Obt: POLYGON((10 10,20 10,20 0,10 0,0 0,0 10,10 10))
FAILED
    1. cu_buildarea.c:94  - 0
  Test: buildarea3 ...passed
  Test: buildarea4 ... Failure at cu_buildarea.c:164
 Exp: MULTIPOLYGON(((0 0,0 20,20 20,20 0,0 0),(2 2,18 2,18 18,2 18,2 2)),((8 8,8
 12,12 12,12 8,8 8)))
 Obt: MULTIPOLYGON(((8 8,8 12,12 12,12 8,8 8)),((0 0,0 20,20 20,20 0,0 0),(2 2,1
8 2,18 18,2 18,2 2)))
FAILED
    1. cu_buildarea.c:164  - 0
  Test: buildarea4b ...passed
  Test: buildarea5 ... Failure at cu_buildarea.c:236
 Exp: MULTIPOLYGON(((0 0,0 20,20 20,20 0,0 0),(2 2,18 2,18 18,2 18,2 2)),((8 8,8
 12,12 12,12 8,8 8)))
 Obt: MULTIPOLYGON(((8 8,8 12,12 12,12 8,8 8)),((0 0,0 20,20 20,20 0,0 0),(2 2,1
8 2,18 18,2 18,2 2)))
FAILED
    1. cu_buildarea.c:236  - 0
  Test: buildarea6 ...passed
  Test: buildarea7 ... Failure at cu_buildarea.c:310
 Exp: MULTIPOLYGON(((80 0,80 70,110 70,110 0,80 0),(90 60,90 50,100 50,100 60,90
 60)),((20 20,20 30,20 50,30 50,30 30,30 20,20 20)),((0 0,0 70,70 70,70 0,0 0),(
50 20,60 20,60 40,60 60,50 60,50 40,50 20),(10 10,40 10,40 60,10 60,10 10)))
 Obt: MULTIPOLYGON(((80 0,80 70,110 70,110 0,80 0),(90 60,90 50,100 50,100 60,90
 60)),((20 20,20 30,20 50,30 50,30 30,30 20,20 20)),((0 0,0 70,70 70,70 0,0 0),(
50 40,50 20,60 20,60 40,60 60,50 60,50 40),(10 10,40 10,40 60,10 60,10 10)))
FAILED
    1. cu_buildarea.c:310  - 0

[strk]

I've _added_ the tests first in r9730, and only changed the expected result in r9731 to follow the new algorithm.

[strk]

I could reproduce a failure on a 32bit system with non-updated GEOS, but only with buildarea7:

Suite: buildarea
  Test: buildarea1 ... passed
  Test: buildarea2 ... passed
  Test: buildarea3 ... passed
  Test: buildarea4 ... passed
  Test: buildarea4b ... passed
  Test: buildarea5 ... passed
  Test: buildarea6 ... passed
  Test: buildarea7 ...  Failure at cu_buildarea.c:310
 Exp: MULTIPOLYGON(((80 0,80 70,110 70,110 0,80 0),(90 60,90 50,100 50,100 60,90 60)),((20 20,20 30,20 50,30 50,30 30,30 20,20 20)),((0 0,0 70,70 70,70 0,0 0),(10 10,40 10,40 60,10 60,10 10),(50 20,60 20,60 40,60 60,50 60,50 40,50 20)))
 Obt: GEOMETRYCOLLECTION(POLYGON((80 0,80 70,110 70,110 0,80 0),(90 60,90 50,100 50,100 60,90 60)),LINESTRING(60 40,50 40),POLYGON((20 20,20 30,20 50,30 50,30 30,30 20,20 20)),POLYGON((0 0,0 70,70 70,70 0,0 0),(10 10,40 10,40 60,10 60,10 10),(50 20,60 20,60 40,60 60,50 60,50 40,50 20)))
FAILED
    1. cu_buildarea.c:310  - 0

[robe]

hmm but that was running the latest geos 3.3.4dev (r3627). Are you running geos trunk (3.4)?

[strk]

After upgrading to GEOS trunk the error went away. I don't know what GEOS I was running before.

[strk]

r9742 normalizes obtained and expected output before comparing, see if it works for you.

[robe]

seems to work

[robe]

can you make the same fix for sql tests. I suspect its same issue:

regress_bdpoly_expected

-BuildArea|SRID=3;MULTIPOLYGON(((0 0 10,0 10 8,10 10 6,10 0 4,0 0 2),(2 2 5,4 2 4,4 4 3,2 4 2,2 2 1),(5 5 6,7 5 7,7 7 8,5 7 9,5 5 10)),((20 0 10,20 10 8,30 10 6,30 0 4,20 0 2),(22 2 5,24 2 4,24 4 3,22 4 2,22 2 1),(25 5 6,27 5 7,27 7 8,25 7 9,25 5 10)))
-BdMPolyFromText|SRID=3;MULTIPOLYGON(((0 0,0 10,10 10,10 0,0 0),(2 2,4 2,4 4,2 4,2 2),(5 5,7 5,7 7,5 7,5 5)),((20 0,20 10,30 10,30 0,20 0),(22 2,24 2,24 4,22 4,22 2),(25 5,27 5,27 7,25 7,25 5)))
+BuildArea|SRID=3;MULTIPOLYGON(((20 0 10,20 10 8,30 10 6,30 0 4,20 0 2),(22 2 5,24 2 4,24 4 3,22 4 2,22 2 1),(25 5 6,27 5 7,27 7 8,25 7 9,25 5 10)),((0 0 10,0 10 8,10 10 6,10 0 4,0 0 2),(2 2 5,4 2 4,4 4 3,2 4 2,2 2 1),(5 5 6,7 5 7,7 7 8,5 7 9,5 5 10)))
+BdMPolyFromText|SRID=3;MULTIPOLYGON(((20 0,20 10,30 10,30 0,20 0),(22 2,24 2,24 4,22 4,22 2),(25 5,27 5,27 7,25 7,25 5)),((0 0,0 10,10 10,10 0,0 0),(2 2,4 2,4 4,2 4,2 2),(5 5,7 5,7 7,5 7,5 5)))

[robe]

fixed for trunk at r9832

[robe]

fixed on 2.0.1 r9833

Try now on mingw Paul :)