Topology regression failure in regress/topogeo_addlinestring

[pramsey]

OSX 10.8, gdal 1.9.2, postgresql 9.2, postgis 2.1svn

 regress/topogeo_addlinestring .. failed (diff expected obtained: /tmp/pgis_reg/test_29_diff)


--- regress/topogeo_addlinestring_expected      2013-07-13 10:55:48.000000000 -0700
+++ /tmp/pgis_reg/test_29_out   2013-07-13 10:56:04.000000000 -0700
@@ -57,9 +57,9 @@
 E|38|sn36|en17
 E|39|sn35|en36
 E|40|sn17|en35
+snap_again|7
 snap_again|36
 snap_again|39
-snap_again|40
 crossover|43
 crossover|45
 crossover|46
@@ -165,15 +165,14 @@
 E|70|sn70|en71
 #1706.2|E*|70
 #1706.2|E*|72
-#1706.2|E*|73
 N|72||POINT(10 0)
-N|73||POINT(10 10)
-N|74||POINT(15 10)
-E|70|sn70|en74
+N|73||POINT(9 12)
+E|70|sn70|en73
 E|71|sn73|en71
 E|72|sn72|en73
-E|73|sn74|en73
-#1714.1|N|75
-N|75|0|POINT(10 0)
-#1714.2|E*|74
+#1714.1|N|74
+N|74|0|POINT(10 0)
+#1714.2|E*|73
+N|75||POINT(0 20)
+E|73|sn74|en75
 Topology 'city_data' dropped

[pramsey]

Oh, this is at r11681

[robe]

pramsey you forgot to mention which GEOS you are running. I suspect it might be GEOS related since there was a time when strk had regression logic in there that would fail unless you were running an unreleased version of GEOS. I think that has all been taken out but could still be related. I only test with unreleased virgin libraries

[pramsey]

GEOS 3.3.8

[robe]

Hmm I wonder if strk's rollback did not completely work. That's the same regress test that used to fail without the change in upcoming 3.3.9 and 3.4.0.

Which should have been resolved at #2368

[strk]

3.3.8 was considered using "new" snapping. Should be fixed with r11682 in trunk, r11683 in 2.1 branch and r11684 in 2.0 branch

[pramsey]

All my regressions now pass!

[strk]

It turns out the back port to 2.0 didn't work correctly (see #2470). Indeed the patched Makefile in 2.0 is not generated, thus making the GEOS_NUMERIC_VERSION never correct

[strk]

There seems to be a problem with padding zeros in GEOS_NUMERIC_VERSION as I get, in the Makefile:

GEOS_NUMERIC_VERSION=30400

The same happens with postgis-2.1

The problem is that 30400 is < 303008 … defeating the purpose of the check.

Beside, shouldn't it be 030400 and 030308 ?

Paul ?

[strk]

Ah, it was actually a bug in the backport, which added an additional 0 to the expected version of GEOS… fixing

[strk]

Fixed 2.0 branch with r11927 (thanks Travis!)