On 1/12/06, zze-SIGALE PORTANERI F ext RD-BIZZ-SOP <[EMAIL PROTECTED]> wrote: > Hi Frank & Ed, > > Thanks for your prompt and efficient answers!!! > > You're right, the pbm seems to come from the prime meridiam mismatch (and not > decimal degree conversion issue as I thought before). > I was able to confim this by manually doing some conversion tests using the > Convers useful little tool (http://vtopo.free.fr/convers.htm ). > > As per example, for a WGS84 GPS point in Paris: longitude=2.38388 > latitude=48.85562 > > In Lambert II Etendu, I have today (wrong value) : X=775063.135566471 > Y=2431242.54750943 > which is given using "Paris" as origin in Convers and which corresponds to > the postgis transform call : > > psql> select public.transform(GeometryFromText('POINT (2.38388 48.85562)', > 4326), 27582); > SRID=27582;POINT(775063.135566471 2431242.54750943) > > So I have to find other EPSG values to get the correct X/Y that should be: > X=603478.33780249 Y=2428587.76696934. > > I didn't find it yet, but I keep investigating in the spatial_ref_sys postgis > (0.9.1) table!!!
FP, I think what you will need to do is correct the PROJ.4 definition in the spatial_ref_sys table. If you examine the +pm and +lon_0 settings you should be able to adjust things. Generally the problem generating the proj.4 was that the +pm setting was made *and* the +lon_0 was offset by the prime meridian (or something like that). Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent
