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

[strk at refractions.net]

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

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.

--strk;


On Wed, May 18, 2005 at 06:29:17PM +0200, Nicolas Ribot wrote:
> > Now, what about the srtext value ? Should it be changed as well ?
> > 
> 
> I must precise a little bit my previous message:
> 
> I recall I wrote a little document some month ago when I first
> discover problems with new EPSG definitions. (I attach this document
> to my email).
> 
> When testing SRTEXT with Jump and the Coordinate Transform plugin, I
> noticed too other things:
> 
> 1°) The "latitude_of_origin" parameter is given in grad in the
> original definition (55, 52, 49, 46.85 gr) as stated in the UNIT part
> of the definition. Geotools seems to ignore the unit clause and
> expects this value to be in degree:
> 55gr = 49°30´ (49.5) - 52gr = 46°48´ (46.8) - 49gr = 44°06´ (44.1) -
> 46,85gr = 42°09´54 (42.165)
> 
> So I changed this parameter in the 4 SRTEXT to make them work in Jump.
> I think SRTEXT is correct anyway, as it correctly precise the unit in
> which the latitute of origin is defined.
> 
> 2°) The "PRIMEM" parameter is given in degree in the original
> definition, though unit is declared to be "grad". This parameter must
> be converted into grads:
> 2.33722917 deg = 2.5969213 gr.
> 
> Changing this value made the SRTEXT work with Geotools/Jump.
> I think here, SRTEXT is wrong.
> 
> Nicolas