[raster] regression failures

[gdt]

I get two failures on the raster regression tests with:

PostGIS is now configured for i386-unknown-netbsdelf5.1.

-------------- Compiler Info ------------- 
C compiler:           gcc -g -O2
C++ compiler:         g++ -g -O2

-------------- Dependencies -------------- 
GEOS config:          /usr/pkg/bin/geos-config
GEOS version:         3.3.2
GDAL config:          /usr/pkg/bin/gdal-config
GDAL version:         1.8.0
PostgreSQL config:    /usr/pkg/bin/pg_config
PostgreSQL version:   PostgreSQL 9.1.2
PROJ4 version:        47
Libxml2 config:       /usr/pkg/bin/xml2-config
Libxml2 version:      2.7.8
JSON-C support:       no
PostGIS debug level:  0
Perl:                 /usr/pkg/bin/perl

--------------- Extensions --------------- 
PostGIS Raster:       0.1.6d
PostGIS Topology:     enabled

-------- Documentation Generation -------- 
xsltproc:             /usr/pkg/bin/xsltproc
xsl style sheets:     /usr/pkg/share/xsl/docbook
dblatex:              
convert:              /usr/pkg/bin/convert

The diffs follow, but basically I seem to get NaN instead of a value. I ran "paranoia"*, which when compiled with -ffloat-store was totally happy with my compiler/library/processor's arithmetic. So, while realizing that my results seem off, I wonder if

• anyone else sees this

• if the tests assume i386 extended double registers

• if the tests are known to pass on non-i386 (eg. sparc64) with a different floating point implementation

• anyone has any other clues

I will update gdal and retry, but 1.8.0 is ≥ 1.6.0 which is documented to work.

--- rt_rotation_expected	2012-01-12 20:47:29.000000000 -0500
+++ /tmp/pgis_reg_14681/test_18_out	2012-01-25 19:12:25.000000000 -0500
@@ -1,8 +1,8 @@
-4|1x1, ip:7.5,2.5 scale:5,5 skew:1,1, srid:-1, width:1, height:1|0.197395559849881
+4|1x1, ip:7.5,2.5 scale:5,5 skew:1,1, srid:-1, width:1, height:1|NaN
 5|1x1, ip:7.5,2.5 scale:5,5 skew:3,7, srid:-1, width:1, height:1|NaN
 104|5.09901951359278|5.09901951359278|0|0|0
 105|8.60232526704263|5.8309518948453|0|0|0
-104|3.60555127546399|3.60555127546399|3.60555127546399|3.60555127546399|0.785398163397448
-105|6.08276253029822|4.12310562561766|4.12310562561766|6.08276253029822|0.785398163397448
-104|4.41588043316392|4.41588043316392|2.54950975679639|2.54950975679639|0.523598775598299
-105|7.44983221287567|5.04975246918104|2.91547594742265|4.30116263352131|0.523598775598299
+104|3.60555127546399|3.60555127546399|3.60555127546399|3.60555127546399|NaN
+105|6.08276253029822|4.12310562561766|4.12310562561766|6.08276253029822|NaN
+104|4.41588043316392|4.41588043316392|2.54950975679639|2.54950975679639|NaN
+105|7.44983221287567|5.04975246918104|2.91547594742265|4.30116263352131|NaN

--- rt_mapalgebrafctngb_userfunc_expected	2012-01-12 20:47:29.000000000 -0500
+++ /tmp/pgis_reg_14681/test_48_out	2012-01-25 19:12:31.000000000 -0500
@@ -26,6 +26,6 @@
 t|t
 t|t
 t|t
-t|t
+ERROR:  input is out of range
 t
 t

• ​http://www.netlib.org/paranoia/

[dustymugs]

Fixed the issue with rt_rotation in r8974. I'll see if I can find out what rt_mapalgebrafctngb_userfunc is doing.

[gdt]

Thanks - at r8986, I can confirm that the rt_rotation test case passes (and rt_mapalgebrafctngb_userfunc still fails).

[dustymugs]

Can you try running the following query in psql and attach the output to this ticket?

\set VERBOSITY verbose

SELECT
  ST_Value(rast, 2, 2) = 1,
  round(ST_Value(
    ST_Hillshade(rast, 1, NULL, 0.0, pi()/4.0, 255), 2, 2
  )*10000) = 1803122
  FROM ST_TestRasterNgb(3, 3, 1) AS rast;

[gdt]

(I had to load raster/test/regress/create_rt_mapalgebrafctngb_test.sql.)

psql (9.1.2)
Type "help" for help.

gdt=#  \set VERBOSITY verbose
gdt=# 
gdt=#  SELECT
gdt-#    ST_Value(rast, 2, 2) = 1,
gdt-#    round(ST_Value(
gdt(#      ST_Hillshade(rast, 1, NULL, 0.0, pi()/4.0, 255), 2, 2
gdt(#    )*10000) = 1803122
gdt-#    FROM ST_TestRasterNgb(3, 3, 1) AS rast;
ERROR:  22003: input is out of range
CONTEXT:  PL/pgSQL function "_st_hillshade4ma" line 22 at assignment
LOCATION:  datan2, float.c:1540

[dustymugs]

Can you try r9007? I've added a check for when atan2 is called with atan(0, 0).

[gdt]

With that, it passes. However, it then has a similar creating-already-created problem as ticket:1499 :

psql:/home/gdt/SOFTWARE/POSTGIS/postgis/regress/00-regress-install/share/contrib/postgis/rtpostgis_upgrade_20_minor.sql:446: ERROR:  type "raster" already exists

Thanks for the floating point fixes.

[dustymugs]

The floating point and atan2() fixes shouldn't have affected that. Could you clean, rebuild and try again?

[gdt]

I did; my test setup is to svn up, gmake clean, run autogen, run configure, build, and so on. What I meant is not that your atan2 fix caused the other problem, but that the other problem was now visible, whereas before the test never got that far, so I agree that the changes you made should not have affected the new problem, and I believe that they did not affect the new problem. Specifically, the first round of tests pass, and there is an error doing the upgrade.

Why do you think "create type raster" is ok in a database that already has that type? (See line 446 of postgis_update_20_minor.sql.) Everything else is "create or replace", but "create or replace type" seems not legit.

[dustymugs]

I'm wondering if you can check your rtpostgis_upgrade_20_minor.sql file and see if you can find "CREATE TYPE raster". I just checked my generated rtpostgis_upgrade_20_minor.sql and there is no type creation. I think that statement is the only way for that error message.

[gdt]

The issue is the sed that's trying to remove CREATE TYPE et al. I think that GNU sed may be required, rather than traditional sed, but I don't understand yet.

[gdt]

I'm going to call the original problem fixed, because the other issue has nothing to do with it. Thanks for addressing it.