Make check errors on Mac - spheroid area - srid 32702

[colivier]

Cunit error:

Test: test_spheroid_area() ... FAILED

1. cu_geodetic.c:968 - CU_ASSERT_DOUBLE_EQUAL(a1,a2,0.2)
2. cu_geodetic.c:976 - CU_ASSERT_DOUBLE_EQUAL(a1,a2,100000000.0)

And a regress one:

* tickets_expected Thu Jan 28 14:54:28 2010 --- /var/folders/lq/lq3l11tSFeyWgrx8TopGk++++TI/-Tmp-test_47_out Thu Jan 28 15:32:24 2010 * * 64,66 --- 64,67 ----

#277|<gml:Point><gml:coordinates>1,1e+308</gml:coordinates></gml:Point> #299|2 #304

+ ERROR: GetProj4StringSPI: Cannot find SRID (32702) in spatial_ref_sys

PostgreSQL 8.3.7 on i386-apple-darwin9.6.2, compiled by GCC i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490) Postgis 1.5.0SVN - 2010-01-28 14:06:14

GEOS: 3.2.0-CAPI-1.6.0 PROJ: Rel. 4.6.1, 21 August 2008

r5172

[mcayland]

Hmmm I think looking at regress/run_test that it doesn't actually load spatial_ref_sys.sql during a regression run. Can you try a quick patch and see if that fixes it?

What is more worrying is that if I abort my regression tests part way through and check the postgis_reg database manually, the spatial_ref_sys table seems to be there...

Mark.

[mcayland]

Ah I see - I think regress/tickets.sql is missing an INSERT into spatial_ref_sys at the top of the file. Though I still don't see why it isn't broken for everyone else.

[colivier]

Well that's not look 'that' simple, if i insert the 2 missing srid:

Index: tickets.sql
===================================================================
--- tickets.sql	(revision 5172)
+++ tickets.sql	(working copy)
@@ -6,6 +6,8 @@
 DELETE FROM spatial_ref_sys;
 INSERT INTO spatial_ref_sys ( srid, proj4text ) VALUES ( 32611, '+proj=utm +zone=11 +ellps=WGS84 +datum=WGS84 +units=m +no_defs' );
 INSERT INTO spatial_ref_sys ( srid, proj4text ) VALUES ( 4326, '+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs' );
+INSERT INTO spatial_ref_sys ( srid, proj4text ) VALUES ( 32602, '+proj=utm +zone=2 +ellps=WGS84 +datum=WGS84 +units=m +no_defs ' );
+INSERT INTO spatial_ref_sys ( srid, proj4text ) VALUES ( 32702, '+proj=utm +zone=2 +south +ellps=WGS84 +datum=WGS84 +units=m +no_defs ' );

Produce this new regress output (cunit fails are obviously still the same):

*** tickets_expected	Thu Jan 28 14:54:28 2010
--- /var/folders/lq/lq3l11tSFeyWgrx8TopGk++++TI/-Tmp-//test_47_out	Thu Jan 28 16:14:40 2010
***************
*** 64,66 ****
--- 64,76 ----
  #277|<gml:Point><gml:coordinates>1,1e+308</gml:coordinates></gml:Point>
  #299|2
  #304
+ POINT(-170 -80)|0.000115919886854499|0.00011467046914504
+ POINT(-170 -70)|5.82107245751251e-5|5.56136178916367e-5
+ POINT(-170 -60)|3.50390659657751e-5|3.50390659657751e-5
+ POINT(-170 -50)|2.41302911850039e-5|2.41302911850039e-5
+ POINT(-170 -40)|1.70080525747629e-5|1.70080525747629e-5
+ POINT(-170 -30)|1.17068806768372e-5|1.17068806768372e-5
+ POINT(-170 -20)|7.38417888529463e-6|7.38417888529463e-6
+ POINT(-170 -10)|3.57911220325025e-6|3.57911220325025e-6
+ POINT(-170 10)|3.58120134247297e-6|3.58120134247297e-6
+ POINT(-170 20)|7.38386138654512e-6|7.38386138654512e-6

[colivier]

commited a first fix as 5175 for regress issue. Need to be test with other platforms.

(Cunit issue is still on)

[mcayland]

This breaks for me with an inverse of your diff:

* tickets_expected Thu Jan 28 15:35:00 2010 --- /tmp/pgis_reg_20392/test_47_out Thu Jan 28 15:35:51 2010 * * 64,76

#277|<gml:Point><gml:coordinates>1,1e+308</gml:coordinates></gml:Point> #299|2 #304

• POINT(-170 -80)|0.000115919886854499|0.00011467046914504
• POINT(-170 -70)|5.82107245751251e-5|5.56136178916367e-5
• POINT(-170 -60)|3.50390659657751e-5|3.50390659657751e-5
• POINT(-170 -50)|2.41302911850039e-5|2.41302911850039e-5
• POINT(-170 -40)|1.70080525747629e-5|1.70080525747629e-5
• POINT(-170 -30)|1.17068806768372e-5|1.17068806768372e-5
• POINT(-170 -20)|7.38417888529463e-6|7.38417888529463e-6
• POINT(-170 -10)|3.57911220325025e-6|3.57911220325025e-6
• POINT(-170 10)|3.58120134247297e-6|3.58120134247297e-6
• POINT(-170 20)|7.38386138654512e-6|7.38386138654512e-6

--- 64,66 ----

I'd do a fresh checkout on your Mac to make sure it's not a local change that managed to sneak in. As for the CUnit error, over to Paul...

[pramsey]

colivier, the correct answer for ticket #304 is in fact "no results" so your "fix" is just going to break everyone else (like me) the problem is in the actual st_area(geography) calculation on your platform in particular, so we should be focussing our attention on the cunit test failures instead

[pramsey]

btw, what is your platform, exactly. I have this:

pramsey$ uname -a
Darwin Heron-2.local 10.2.0 Darwin Kernel Version 10.2.0: Tue Nov  3 10:37:10 PST 2009; root:xnu-1486.2.11~1/RELEASE_I386 i386
pramsey$ gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) (dot 1)

[colivier]

Ok i revert the previous commit (and keep only the srid part)

$ uname -a
Darwin courtin-oliviers-macbook.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386

$ gcc --version
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[pramsey]

I just looked more closely at your results, and the numbers being reported are just insanely small, it's like either the buffer or the area calculation are being carried out in geometry space, not in geography space. Can you break down the test case and see what is happening in the st_transform() step (are the coordinates being shifted, in fact?) in the st_buffer() step (for both geometry and geography) and the st_area() step (again for both geometry and geography)?

[colivier]

     the_pt      |       the_area       |              geog_utm_area               
-----------------+----------------------+------------------------------------------
 POINT(-170 -80) | 0.000115919886854499 | POINT(519384.803295972 1118247.58518847)
 POINT(-170 -70) | 5.82107245751251e-05 | POINT(538169.782260327 2233813.84855605)
 POINT(-170 -60) | 3.50390659657751e-05 | POINT(555776.26675161 3348167.26456303)
 POINT(-170 -50) | 2.41302911850039e-05 | POINT(571666.447503441 4460890.18469981)
 POINT(-170 -40) | 1.70080525747629e-05 | POINT(585360.461842782 5571763.93536657)
 POINT(-170 -30) | 1.17068806768372e-05 | POINT(596450.152566998 6680793.77724325)
 POINT(-170 -20) | 7.38417888529463e-06 | POINT(604609.323831738 7788206.44383463)
 POINT(-170 -10) | 3.57911220325025e-06 | POINT(609600.772514415 8894421.4108076)
 POINT(-170 10)  | 3.58120134247297e-06 | POINT(609600.772514415 1105578.5891924)
 POINT(-170 20)  | 7.38386138654512e-06 | POINT(604609.323831738 2211793.55616537)
(10 rows)

foo=# SELECT ST_AsText(the_geog) as the_pt, ST_Area(ST_Buffer(the_geog,10)) As the_area,                                               ST_AsText(ST_Transform(geometry(the_geog),utm_srid)) As geog_utm_area                                                  FROM (SELECT geography(ST_SetSRID(ST_Point(i*10,j*10),4326)) As the_geog, utmzone(ST_SetSRID(ST_Point(i*10,j*10),4326)) As utm_srid                                                                                                                                   FROM generate_series(-17,17) As i                                                                                              CROSS JOIN generate_series(-8,8) As j                                                                                  ) As foo                                                                                                                       WHERE ST_Area(ST_Buffer(the_geog,10)) NOT between 310 and 314                                                                  
LIMIT 10;

[pramsey]

It's a heisenbug. If you print out values, it goes away... in fact, if you print out pretty much anything at all, it goes away... here's a patch that "fixes" it. It doesn't matter which value you print out. I managed to fix other variants of this kind of thing, but they were all based on branching issues: two values almost the same and the branch condition was sensitive enough that the print statement seemed to move things a little and change the branch. But in this case, there's no branch conditions that I can see. Google information on heisenbugs points to uninitialized memory as a possible cause, but there's not really any of that in the code path. I dunno. Suggestions on going forward?

[pramsey]

Kick over the printing subsystem and issue goes away.

[pramsey]

Breakthrough: -ffloat-store as a CFLAG makes the problem go away too. Now: apply globally or as a fix for this platform/compiler only?

[pramsey]

Fix using a compiler flag instead...

[pramsey]

Keep floats out of registers for spheroid calculation. Fixes odd bug in OS/X gcc 4.1. Could probably be narrowed to only us e flag on affected platform. Committed at r5180