Opened 13 years ago

Closed 13 years ago

#1213 closed defect (fixed)

[raster] RT_Intersects test fails

Reported by: strk Owned by: dustymugs
Priority: medium Milestone: PostGIS 2.0.0
Component: raster Version: master
Keywords: Cc:

Description

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

Change History (20)

comment:1 by pracine, 13 years ago

Summary: RT_Intersects test fails → [raster] RT_Intersects test fails

comment:2 by dustymugs, 13 years ago

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.

comment:3 by strk, 13 years ago

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.

comment:4 by dustymugs, 13 years ago

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.

comment:5 by robe, 13 years ago

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.

comment:6 by dustymugs, 13 years ago

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

comment:7 by strk, 13 years ago

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

comment:8 by dustymugs, 13 years ago

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

comment:9 by strk, 13 years ago

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 ?

comment:10 by dustymugs, 13 years ago

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

comment:11 by dustymugs, 13 years ago

Have you had a chance to test this again?

comment:12 by strk, 13 years ago

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

comment:13 by dustymugs, 13 years ago

Owner: changed from pracine to dustymugs
Status: new → assigned

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?

comment:14 by strk, 13 years ago

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)

comment:15 by strk, 13 years ago

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…

comment:16 by dustymugs, 13 years ago

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.

in reply to:  15 comment:17 by dustymugs, 13 years ago

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.

comment:18 by dustymugs, 13 years ago

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.

comment:19 by dustymugs, 13 years ago

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.

comment:20 by strk, 13 years ago

Resolution: → fixed
Status: assigned → closed

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!

Note: See TracTickets for help on using tickets.