[postgis-devel] Re: [postgis-users] Re: Buggy transform() function in 1.0RC1 ?

[Nicolas Ribot]

Hello all,

> Nicolas, in the pdf you sent (good work!) you tell previous
> postgis versions worked fine. I took a look at older definitions
> and I found out that both +pm and +lon_0 have the same value
> (2.337229166666667). New definition changed the +pm to Paris
> (instead of literal number) and that seems to have broken things up.
> 
> Changing lon_0 to 0 fixed it again.
> 
> Can you confirm these being the working options:
>         1) +pm=Paris +lon_0=0
>         2) +pm=2.337229166666667 +lon_0=2.337229166666667
> 

I made some tests on Postgis 1.0 (same config as the one described in
my previous message):

The only working option is:
 +pm=paris +lon_0=0

The other option gives the same result as the default proj4text
provided with spatial_ref_sys.sql (+pm=paris +lon_0=2.33722917): a
2.337... coordinates east shift.

By the way, following Gino's advice, I changed the +pm=paris parameter
to +pm=Paris to test if case is sensitive in reprojection.
It crashed the server (postgres.exe).

I send you a minimal script to test the problem.

> It would help testing both with different proj4 versions.
> I don't whether they should be equivalent, but really do
> not look like they are (unless Paris resolves to 2.337*2).
> 
> SRTEXT is not used by postgis, dunno about JUMP.
> 

For me, the correct definition is either:
+pm=paris +lon_0=0 or
+pm=2.33722917 +lon_0=0

expressing the prime meridien either by a keyword or by its actual
shift value from Greenwich.

Nicolas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_crash_postgres_reprojection.sql
Type: application/octet-stream
Size: 775 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20050526/4628c605/attachment.obj>