[raster] RT_Intersects test fails

[strk]

As of r7893:

 PostgreSQL 8.4.8 on x86_64-pc-linux-gnu, compiled by GCC gcc-4.4.real (Ubuntu 4.4.3-4ubuntu5) 4.4.3, 64-bit
 Postgis 2.0.0SVN - 2011-09-26 14:35:30
   GEOS: 3.3.1dev-CAPI-1.7.1
   PROJ: Rel. 4.7.1, 23 September 2009

--- rt_intersects_expected      2011-09-23 21:16:51.000000000 +0200
+++ /tmp/pgis_reg_21649/test_58_out     2011-09-26 16:36:46.000000000 +0200
@@ -168,17 +168,17 @@
 2.4|2|44|ST_MultiPolygon|t
 2.4|2|45|ST_MultiPolygon|t
 2.4|2|46|ST_MultiPolygon|t
-2.5|0|1|ST_Point|t
-2.5|0|2|ST_Point|t
-2.5|0|3|ST_Point|t
-2.5|0|4|ST_Point|t
+2.5|0|1|ST_Point|f
+2.5|0|2|ST_Point|f
+2.5|0|3|ST_Point|f
+2.5|0|4|ST_Point|f
 2.5|0|5|ST_Point|f
 2.5|0|6|ST_Point|f
 2.5|0|7|ST_Point|f
 2.5|0|8|ST_Point|f
-2.5|0|11|ST_MultiPoint|t
-2.5|0|12|ST_MultiPoint|t
-2.5|0|13|ST_MultiPoint|t
+2.5|0|11|ST_MultiPoint|f
+2.5|0|12|ST_MultiPoint|f
+2.5|0|13|ST_MultiPoint|f
 2.5|0|14|ST_MultiPoint|f          
 2.5|0|15|ST_MultiPoint|f
 2.5|0|21|ST_LineString|t
@@ -202,19 +202,19 @@
 2.5|0|44|ST_MultiPolygon|t
 2.5|0|45|ST_MultiPolygon|f
 2.5|0|46|ST_MultiPolygon|f
-2.6|2|1|ST_Point|t
-2.6|2|2|ST_Point|t
+2.6|2|1|ST_Point|f
+2.6|2|2|ST_Point|f
 2.6|2|3|ST_Point|f
 2.6|2|4|ST_Point|f
 2.6|2|5|ST_Point|f
 2.6|2|6|ST_Point|f
 2.6|2|7|ST_Point|f
-2.6|2|8|ST_Point|t
-2.6|2|11|ST_MultiPoint|t
-2.6|2|12|ST_MultiPoint|t
-2.6|2|13|ST_MultiPoint|t
-2.6|2|14|ST_MultiPoint|t
-2.6|2|15|ST_MultiPoint|t
+2.6|2|8|ST_Point|f
+2.6|2|11|ST_MultiPoint|f
+2.6|2|12|ST_MultiPoint|f
+2.6|2|13|ST_MultiPoint|f
+2.6|2|14|ST_MultiPoint|f
+2.6|2|15|ST_MultiPoint|f
 2.6|2|21|ST_LineString|t
 2.6|2|22|ST_LineString|t
 2.6|2|23|ST_LineString|t

[dustymugs]

What version and revision of GDAL are you using? I'm using GDAL trunk r23097. I had been using an older version of trunk and the rasters created from geometries were different.

[strk]

I think r22523 (1.9.0) I can update to current SVN, but is anyone testing with official gdal releases ? It's important that the regression tests deal properly with any supported official gdal release.

Let me know if you want me to upgrade or keep the old version around.

[dustymugs]

Can you upgrade and try again? I'll adjust the regression test to use scales gte 1 as I believe scales less than 1 cause issues.

[robe]

Mine is failing too now. I'm running GDAL trunk r23095.

This I think is because you didn't take out the old function in the regress test since in the diff I get this error.

ERROR:  function st_intersects(raster, integer, raster, integer) does not exist
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.

so guess different from Sandro's failure.

[dustymugs]

Regina, I'm going to respond to you in #1212 so as not to pollute this ticket.

[strk]

Argh, fails in another way with r23125 but seems related to the mess with signatures now:

ERROR: function st_intersects(raster, integer, raster, integer) does not exist

[dustymugs]

OK. I'm going to change the regression test so that it passes with GDAL versions >= 1.6.0.

[strk]

Well, my test didn't reveal anything, what's this decision about ? Let's wait for the signature to get back in before moving on here ?

[dustymugs]

Sounds good to me. Ticket #1212 is discussing the signature issue.

[dustymugs]

Have you had a chance to test this again?

[strk]

Still failing as of r7927:

--- rt_intersects_expected      2011-10-01 13:46:55.000000000 +0200
+++ /tmp/pgis_reg_22068/test_58_out     2011-10-02 13:49:31.000000000 +0200
@@ -168,17 +168,17 @@
 2.4|2|44|ST_MultiPolygon|t
 2.4|2|45|ST_MultiPolygon|t
 2.4|2|46|ST_MultiPolygon|t
-2.5|0|1|ST_Point|t
-2.5|0|2|ST_Point|t
-2.5|0|3|ST_Point|t
-2.5|0|4|ST_Point|t
+2.5|0|1|ST_Point|f
+2.5|0|2|ST_Point|f
+2.5|0|3|ST_Point|f
+2.5|0|4|ST_Point|f
 2.5|0|5|ST_Point|f
 2.5|0|6|ST_Point|f
 2.5|0|7|ST_Point|f
 2.5|0|8|ST_Point|f

-2.5|0|11|ST_MultiPoint|t
-2.5|0|12|ST_MultiPoint|t
-2.5|0|13|ST_MultiPoint|t
+2.5|0|11|ST_MultiPoint|f
+2.5|0|12|ST_MultiPoint|f
+2.5|0|13|ST_MultiPoint|f
 2.5|0|14|ST_MultiPoint|f
 2.5|0|15|ST_MultiPoint|f
 2.5|0|21|ST_LineString|t
@@ -202,19 +202,19 @@
 2.5|0|44|ST_MultiPolygon|t
 2.5|0|45|ST_MultiPolygon|f
 2.5|0|46|ST_MultiPolygon|f
-2.6|2|1|ST_Point|t
-2.6|2|2|ST_Point|t
+2.6|2|1|ST_Point|f
+2.6|2|2|ST_Point|f
 2.6|2|3|ST_Point|f
 2.6|2|4|ST_Point|f
 2.6|2|5|ST_Point|f
 2.6|2|6|ST_Point|f
 2.6|2|7|ST_Point|f

-2.6|2|8|ST_Point|t
-2.6|2|11|ST_MultiPoint|t
-2.6|2|12|ST_MultiPoint|t
-2.6|2|13|ST_MultiPoint|t
-2.6|2|14|ST_MultiPoint|t
-2.6|2|15|ST_MultiPoint|t
+2.6|2|8|ST_Point|f
+2.6|2|11|ST_MultiPoint|f
+2.6|2|12|ST_MultiPoint|f
+2.6|2|13|ST_MultiPoint|f
+2.6|2|14|ST_MultiPoint|f
+2.6|2|15|ST_MultiPoint|f
 2.6|2|21|ST_LineString|t
 2.6|2|22|ST_LineString|t
 2.6|2|23|ST_LineString|t

[dustymugs]

Can you run the following query?

SELECT ST_Intersects(

ST_AddBand(

ST_MakeEmptyRaster(2, 2, -1, -1, 1, 1, 0, 0, 0), 1, '8BUI', 1, 0

), ST_MakePoint(0, 0)

, 1);

The result should be TRUE. If it is FALSE, is it possible to get the output from a debug build of PostGIS?

[strk]

Returns true, as expected. Note that the same PostGIS revision, with the same GDAL revision, passes regress testing on my 64bit machine. The problem reported in my last comment happens on a 32bit host:

 PostgreSQL 8.4.8 on i486-pc-linux-gnu, compiled by GCC gcc-4.4.real (Ubuntu 4.4
.3-4ubuntu5) 4.4.3, 32-bit
 Postgis 2.0.0SVN - 2011-10-02 11:47:45
   GEOS: 3.3.0-CAPI-1.7.0
   PROJ: Rel. 4.7.1, 23 September 2009

Too bad there's no GDAL version in that header (see #1225)

[strk]

I've updated gdal to r23167 and the new failure (on the 32bit, with postgis r7931) is:

--- rt_intersects_expected      2011-10-01 13:46:55.000000000 +0200
+++ /tmp/pgis_reg_23053/test_58_out     2011-10-02 20:54:56.000000000 +0200
@@ -218,7 +218,7 @@
 2.6|2|21|ST_LineString|t
 2.6|2|22|ST_LineString|t
 2.6|2|23|ST_LineString|t
-2.6|2|24|ST_LineString|t
+2.6|2|24|ST_LineString|f
 2.6|2|25|ST_LineString|t
 2.6|2|26|ST_LineString|t
 2.6|2|27|ST_LineString|t

We seem to be closer...

[dustymugs]

Strange. My dev environment is 32-bit linux and I test on 64-bit linux and OSX and valgrind everything before I commit anything so these regressions are strange. I'm going to have to check rt_raster_gdal_rasterize to see what the raster generated for that failing test looks like.

[dustymugs]

Replying to strk:

I've updated gdal to r23167 and the new failure (on the 32bit, with postgis r7931) is: {{{ --- rt_intersects_expected 2011-10-01 13:46:55.000000000 +0200 +++ /tmp/pgis_reg_23053/test_58_out 2011-10-02 20:54:56.000000000 +0200 @@ -218,7 +218,7 @@ 2.6|2|21|ST_LineString|t 2.6|2|22|ST_LineString|t 2.6|2|23|ST_LineString|t -2.6|2|24|ST_LineString|t +2.6|2|24|ST_LineString|f 2.6|2|25|ST_LineString|t 2.6|2|26|ST_LineString|t 2.6|2|27|ST_LineString|t }}} We seem to be closer...

Can you try the following on the 32-bit machine? The query is equivalent to the raster and geometry failing in the regression.

SELECT ST_Intersects(
	ST_AddBand(
		ST_MakeEmptyRaster(3, 3, 0, 0, 1, 1, 0, 0, 0),
		1, '8BUI', 1, 0
	),
	ST_MakeLine(ARRAY[
		ST_MakePoint(-1.1, 1.1),
		ST_MakePoint(1.1, 1.1),
		ST_MakePoint(1.1, -1.1),
		ST_MakePoint(-1.1, -1.1),
		ST_MakePoint(-1.1, 1.1)
	])
, 1);

The query should result in TRUE.

[dustymugs]

Thanks for the log.

 http://postgis.refractions.net/pipermail/postgis-devel/2011-October/015413.html

I was able to replicate the regression error by disabling --enable-debug when building gdal. I'll have to do some digging.

[dustymugs]

Can you try r7941? After discussing with Frank ( http://trac.osgeo.org/gdal/ticket/4274), I've made a slight change that affects the extent of the raster created from a geometry.

[strk]

Finally fixed. Tested with r7948 of postgis and r23167 of gdal on the 32bit system. It took a while as I had to remove an old copy of GDAL left in the system and wasn't that easy to correctly build GDAL to have the NumPy? support, but I think this bug can be fixed now.

Next time we'll have better gdal versioning info :) Thanks!