Opened 15 years ago
Closed 15 years ago
#395 closed defect (fixed)
Make check errors on Mac - spheroid area - srid 32702
Reported by: | colivier | Owned by: | pramsey |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 1.5.0 |
Component: | postgis | Version: | master |
Keywords: | Mac regress spheroid_area 32702 | Cc: |
Description
Cunit error:
Test: test_spheroid_area() … FAILED
- cu_geodetic.c:968 - CU_ASSERT_DOUBLE_EQUAL(a1,a2,0.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
Attachments (2)
Change History (15)
comment:1 by , 15 years ago
comment:2 by , 15 years ago
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.
comment:3 by , 15 years ago
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
comment:4 by , 15 years ago
commited a first fix as 5175 for regress issue. Need to be test with other platforms.
(Cunit issue is still on)
comment:5 by , 15 years ago
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…
comment:6 by , 15 years ago
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
comment:7 by , 15 years ago
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)
comment:8 by , 15 years ago
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.
comment:9 by , 15 years ago
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)?
comment:10 by , 15 years ago
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;
comment:11 by , 15 years ago
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?
by , 15 years ago
Attachment: | heisen.patch added |
---|
Kick over the printing subsystem and issue goes away.
comment:12 by , 15 years ago
Breakthrough: -ffloat-store as a CFLAG makes the problem go away too. Now: apply globally or as a fix for this platform/compiler only?
comment:13 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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
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.