From fabrice_martin2 at yahoo.fr  Sat Jun  2 08:23:51 2007
From: fabrice_martin2 at yahoo.fr (fabrice martin)
Date: Sat Jun  2 08:24:04 2007
Subject: [Proj] Why use pj_inv() and pj_fwd() instead of pj_transform() ?
Message-ID: <216464.63237.qm@web26603.mail.ukl.yahoo.com>

Hello,



I'm a recent user of PROJ.4, and I don't exactly understand the
difference between pj_inv(), pj_fwd() and pj_transform() ? Or said
differently, why use proj and invproj instead of cs2cs ? I have the
impression that cs2cs is more powerful than the other programs, since
it can handle prime meridians (+pm), and also geographic coordinates
with +longlat .

Are there special features in pj_inv(), pj_fwd(), or has it been superceded by pj_transform() ?



Thank you,

Fabrice



if( self == top ) {
	Nabble.writeReturnToLink(
		'<a href="'
		+( Nabble.tview == "dump"
			? 'http://www.nabble.com/Why-use-pj_inv%28%29-and-pj_fwd%28%29-instead-of-pj_transform%28%29---t3848719.html'
			: 'http://www.nabble.com/Why-use-pj_inv%28%29-and-pj_fwd%28%29-instead-of-pj_transform%28%29---tf3848719.html'
		)
		+ '" target="_top">Return to thread</a>'
	);
} else if( Nabble.prev )
	Nabble.writeReturnToLink(Nabble.prev);




      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail 
From warmerdam at pobox.com  Sat Jun  2 15:39:51 2007
From: warmerdam at pobox.com (Frank Warmerdam)
Date: Sat Jun  2 15:40:34 2007
Subject: [Proj] Why use pj_inv() and pj_fwd() instead of pj_transform() ?
In-Reply-To: <216464.63237.qm@web26603.mail.ukl.yahoo.com>
References: <216464.63237.qm@web26603.mail.ukl.yahoo.com>
Message-ID: <4661C787.10504@pobox.com>

fabrice martin wrote:
> Hello,
> 
> 
> 
> I'm a recent user of PROJ.4, and I don't exactly understand the
> difference between pj_inv(), pj_fwd() and pj_transform() ? Or said
> differently, why use proj and invproj instead of cs2cs ? I have the
> impression that cs2cs is more powerful than the other programs, since
> it can handle prime meridians (+pm), and also geographic coordinates
> with +longlat .
> 
> Are there special features in pj_inv(), pj_fwd(), or has it been superceded by pj_transform() ?

Fabrice,

pj_transform() is a newer function layered on pj_inv() and pj_fwd().  My
intention is that most new applications would use it though there is
some performance overhead to going through it instead of calling the
pj_inv() and pj_fwd() functions directly.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

From fabrice_martin2 at yahoo.fr  Sun Jun  3 06:33:18 2007
From: fabrice_martin2 at yahoo.fr (fabrice martin)
Date: Sun Jun  3 06:33:32 2007
Subject: [Proj] Why use pj_inv() and pj_fwd() instead of pj_transform() ?
Message-ID: <620753.38368.qm@web26601.mail.ukl.yahoo.com>

>Fabrice,
>
>pj_transform() is a newer function layered on pj_inv() and pj_fwd().  My
>intention is that most new applications would use it though there is
>some performance overhead to going through it instead of calling the
>pj_inv() and pj_fwd() functions directly.

Hi Frank,
Thank you for your answer. And could you tell me what's the rationale behind pj_inv() and pj_fwd() not taking into account prime meridians ? It could lead some people to prefer to substitute +lon_0 to +pm in coordinate systems' definitions, so that pj_inv(), pj_fwd() and pj_transform() give the same result !

Best regards,
Fabrice.





      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail 
From geraldi.evenden at gmail.com  Sun Jun  3 10:35:56 2007
From: geraldi.evenden at gmail.com (Gerald I. Evenden)
Date: Sun Jun  3 10:36:03 2007
Subject: [Proj] Why use pj_inv() and pj_fwd() instead of pj_transform() ?
In-Reply-To: <620753.38368.qm@web26601.mail.ukl.yahoo.com>
References: <620753.38368.qm@web26601.mail.ukl.yahoo.com>
Message-ID: <200706031035.56623.geraldi.evenden@gmail.com>

On Sunday 03 June 2007 6:33 am, fabrice martin wrote:
> >Fabrice,
> >
> >pj_transform() is a newer function layered on pj_inv() and pj_fwd().  My
> >intention is that most new applications would use it though there is
> >some performance overhead to going through it instead of calling the
> >pj_inv() and pj_fwd() functions directly.
>
> Hi Frank,
> Thank you for your answer. And could you tell me what's the rationale
> behind pj_inv() and pj_fwd() not taking into account prime meridians ? It
> could lead some people to prefer to substitute +lon_0 to +pm in coordinate
> systems' definitions, so that pj_inv(), pj_fwd() and pj_transform() give
> the same result !

I will answer that as I am the originator of pj_[inv/fwd].

The principle reason is that a prime meridian can easily be compensated for 
with simple modification of the central meridian (+lon_0).  Proj/libproj 
operations are designed to only take care of the mathematics of the 
projection operation: the conversion between the geographic and Cartesian 
spaces.

This is also the reason that datum shifts are also *not* part of traditional 
proj/libproj operations.

-- 
The whole religious complexion of the modern world is due
to the absence from Jerusalem of a lunatic asylum.
-- Havelock Ellis (1859-1939)  British psychologist
From fabrice_martin2 at yahoo.fr  Sun Jun  3 15:19:14 2007
From: fabrice_martin2 at yahoo.fr (fabrice martin)
Date: Sun Jun  3 15:19:28 2007
Subject: [Proj] Why use pj_inv() and pj_fwd() instead of pj_transform() ?
Message-ID: <406711.57346.qm@web26607.mail.ukl.yahoo.com>

>The principle reason is that a prime meridian can easily be compensated for 
>with simple modification of the central meridian (+lon_0). 


In
that case, shouldn't EPSG definitions be modified, in order to use
+lon_0 instead of +pm ? For example, French Lambert projections are
defined with "+lon_0=0 +pm=paris". Wouldn't it be better to use simply
"+lon_0=2.33..." ? It would enable pj_inv, pj_fw and pj_transform to
return similar results.

Regards,
Fabrice.



      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail 
From geraldi.evenden at gmail.com  Sun Jun  3 17:10:14 2007
From: geraldi.evenden at gmail.com (Gerald I. Evenden)
Date: Sun Jun  3 17:10:19 2007
Subject: [Proj] Why use pj_inv() and pj_fwd() instead of pj_transform() ?
In-Reply-To: <406711.57346.qm@web26607.mail.ukl.yahoo.com>
References: <406711.57346.qm@web26607.mail.ukl.yahoo.com>
Message-ID: <200706031710.14251.geraldi.evenden@gmail.com>

On Sunday 03 June 2007 3:19 pm, fabrice martin wrote:
> >The principle reason is that a prime meridian can easily be compensated
> > for with simple modification of the central meridian (+lon_0).
>
> In
> that case, shouldn't EPSG definitions be modified, in order to use
> +lon_0 instead of +pm ? For example, French Lambert projections are
> defined with "+lon_0=0 +pm=paris". Wouldn't it be better to use simply
> "+lon_0=2.33..." ? It would enable pj_inv, pj_fw and pj_transform to
> return similar results.

I personally do not favor a change in either proj/libproj library nor EPSG but 
would suggest that the software using the proj/libproj libraries compensate 
for the adjustment.  Admittedly, my program proj did not prove for prime 
meridians but it was originally designed to be an elementary mechanism to use 
the projection library and in the era that I put the material together I and 
the group using it were total ignorant of varying prime meridians.

As an aside, the fact that proj/libproj provides for false easting and 
northing somewhat compromises my argument for the current handling of the 
prime meridian as these corrections are easily handled external to the 
library.  But the difference here was the UTM projection which is defined as 
part of the library and requires hardwired northing/easting values.

-- 
The whole religious complexion of the modern world is due
to the absence from Jerusalem of a lunatic asylum.
-- Havelock Ellis (1859-1939)  British psychologist
From andrea.aime at gmail.com  Tue Jun  5 11:37:51 2007
From: andrea.aime at gmail.com (aaime74)
Date: Tue Jun  5 11:37:54 2007
Subject: [Proj] 
	Polar stereographic, different values on different platforms?
Message-ID: <10972083.post@talk.nabble.com>


Hi,
at Geoserver we're experiencing some issues with projection code, and we
took Proj as
an external reference for comparison.
Well, it turns out that proj 4.5 returns different results when compiled for
Windows
and Linux.

On Linux:
desruisseaux@adagio ~ $ proj
Rel. 4.5.0, 22 Oct 2006
usage: proj [ -beEfiIlormsStTvVwW [args] ] [ +opts[=arg] ] [ files ]
desruisseaux@adagio ~ $ proj +proj=stere +lon_0=-96.0 +lat_0=90 +lat_ts=71
+ellps=WGS84 +datum=WGS84
-121.33955 39.1012523
-2529570.00     -5341800.00

On Windows:
C:\Program Files\FWTools1.1.3>proj
Rel. 4.5.0, 22 Oct 2006
usage: proj [ -beEfiIlormsStTvVwW [args] ] [ +opts[=arg] ] [ files ]

C:\Program Files\FWTools1.1.3>proj +proj=stere +lon_0=-96.0 +lat_0=90
+lat_ts=71
 +ellps=WGS84 +datum=WGS84
-121.33955 39.1012523
-2544346.32     -5373003.77

The Linux output is in accord with Geoserver and the sample value at
http://www.remotesensing.org/geotiff/proj_list/polar_stereographic.html,
whilst the one on windows seems to be in accord with some old ArcGis
version. Hmmm.... what's going on?

For a full discussion on this issue, see our jira issue track:
http://jira.codehaus.org/browse/GEOS-1037
-- 
View this message in context: http://www.nabble.com/Polar-stereographic%2C-different-values-on-different-platforms--tf3872527.html#a10972083
Sent from the PROJ.4 mailing list archive at Nabble.com.

From warmerdam at pobox.com  Tue Jun  5 13:22:15 2007
From: warmerdam at pobox.com (Frank Warmerdam)
Date: Tue Jun  5 13:12:26 2007
Subject: [Proj]  Polar stereographic,
	different values on different platforms?
In-Reply-To: <10972083.post@talk.nabble.com>
References: <10972083.post@talk.nabble.com>
Message-ID: <46659BC7.5010107@pobox.com>

aaime74 wrote:
> Hi,
> at Geoserver we're experiencing some issues with projection code, and we
> took Proj as
> an external reference for comparison.
> Well, it turns out that proj 4.5 returns different results when compiled for
> Windows
> and Linux.
> 
> On Linux:
> desruisseaux@adagio ~ $ proj
> Rel. 4.5.0, 22 Oct 2006
> usage: proj [ -beEfiIlormsStTvVwW [args] ] [ +opts[=arg] ] [ files ]
> desruisseaux@adagio ~ $ proj +proj=stere +lon_0=-96.0 +lat_0=90 +lat_ts=71
> +ellps=WGS84 +datum=WGS84
> -121.33955 39.1012523
> -2529570.00     -5341800.00
> 
> On Windows:
> C:\Program Files\FWTools1.1.3>proj
> Rel. 4.5.0, 22 Oct 2006
> usage: proj [ -beEfiIlormsStTvVwW [args] ] [ +opts[=arg] ] [ files ]
> 
> C:\Program Files\FWTools1.1.3>proj +proj=stere +lon_0=-96.0 +lat_0=90
> +lat_ts=71
>  +ellps=WGS84 +datum=WGS84
> -121.33955 39.1012523
> -2544346.32     -5373003.77

Andrea,

I think this is related to the recently reported problem in:

   http://bugzilla.remotesensing.org/show_bug.cgi?id=1558

Hopefully I'll be able to resolve it though for your purposes I guess
you should just ignore the windows proj.4 results for now.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

From yjacolin at free.fr  Tue Jun 12 04:33:50 2007
From: yjacolin at free.fr (Jacolin Yves)
Date: Tue Jun 12 04:34:31 2007
Subject: [Proj] Error to convert latlong to lambert2et
Message-ID: <200706121033.51574.yjacolin@free.fr>

Hi,

I tried to used proj4 to convert WGS84 data to lambert 2 etendue (french 
projection, EPSG:27572). Actually, I used a php script that I wrote using an 
algorithme written in a pdf share by French IGN [1], which is correct.

If I try proj4 using the following code:
proj +init="epsg:27572" -S -r
48.816667 2.266667
766532.74       2426646.42

The new data: (766532.74,2426646.42) is not correct. The first should be 
something like 594868, the second one seems correct.

Where do I may wrong?

Regards,

Y.

[1] http://www.ign.fr/telechargement/MPro/geodesie/CIRCE/NTG_71.pdf
-- 
Yves Jacolin
---
http://softlibre.gloobe.org
From mfinn at usgs.gov  Tue Jun 12 05:00:56 2007
From: mfinn at usgs.gov (Michael P Finn)
Date: Tue Jun 12 05:01:46 2007
Subject: [Proj] Michael P Finn of the USGS/ National Geospatial Technical
 Operations Center is out of the office.
Message-ID: <OF7873C593.3E8F98DC-ON862572F8.00318643-862572F8.00318644@usgs.gov>


I will be out of the office starting  06/06/2007 and will not return until
06/25/2007.

I will be unable to check e-mail regularly while I am out. If I can't
respond to your message while I am out, then I will when I return. If you
have anything that cannot wait, please contact my colleague, Dr. E. Lynn
Usery, at usery@usgs.gov.     Mike

From yjacolin at free.fr  Wed Jun 13 14:25:03 2007
From: yjacolin at free.fr (Yves Jacolin)
Date: Wed Jun 13 14:25:09 2007
Subject: [Proj] Error to convert latlong to lambert2et
In-Reply-To: <200706132016.25614.yjacolin@free.fr>
References: <170165433214287@lycos-europe.com>
	<200706132016.25614.yjacolin@free.fr>
Message-ID: <200706132025.04079.yjacolin@free.fr>

Le Mercredi 13 Juin 2007 20:16, Yves Jacolin a ?crit?:
> Hi,
>
> Thanks steberi, you are right ! The complete proj command line is working.
>
> My 27572 code is different from your's (lon_0=0 and some other things). My
> proj version is :
> $ proj
> Rel. 4.5.0, 22 Oct 2006
>
> Regards,
>
> Y.
>
> Le Mercredi 13 Juin 2007 15:48, t steberi a ?crit?:
> > Hi,
> >
> > You can check you have this definition in your epsg file:
> > # NTF (Paris) / Lambert zone II
> > <27572> +proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=2.33722917
> > +k_0=0.99987742 +x_0=600000 +y_0=2200000 +a=6378249.2 +b=6356515
> > +pm=paris +units=m +no_defs  no_defs <>
> >
> > You can also try the explicit command line
> > proj +proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=2.33722917 +k_0=0.99987742
> > +x_0=600000 +y_0=2200000 +a=6378249.2 +b=6356515 +pm=paris +units=m
> > +no_defs -S -r test_file.txt The result (with proj4.5) should be
> > 594815.06       2424247.30
> >
> > Regards,
> > Thomas
> >
> > > De: Jacolin Yves <yjacolin@free.fr>
> > > A: proj@lists.maptools.org
> > > Objet: [Proj] Error to convert latlong to lambert2et
> > > Date: Tue, 12 Jun 2007 10:33:50 +0200
> > >
> > > Hi,
> > >
> > > I tried to used proj4 to convert WGS84 data to lambert 2 etendue
> > > (french projection, EPSG:27572). Actually, I used a php script that I
> > > wrote using an
> > > algorithme written in a pdf share by French IGN [1], which is correct.
> > >
> > > If I try proj4 using the following code:
> > > proj +init="epsg:27572" -S -r
> > > 48.816667 2.266667
> > > 766532.74       2426646.42
> > >
> > > The new data: (766532.74,2426646.42) is not correct. The first should
> > > be something like 594868, the second one seems correct.
> > >
> > > Where do I may wrong?
> > >
> > > Regards,
> > >
> > > Y.
> > >
> > > [1] <a
> > > href=http://www.ign.fr/telechargement/MPro/geodesie/CIRCE/NTG_71.pdf>ht
> > >tp
> > >
> > >:// www.ign.fr/telechargement/MPro/geodesie/CIRCE/NTG_71.pdf</a>--
> > >
> > > Yves Jacolin
> > > ---
> > > <a
> > > href=http://softlibre.gloobe.org>http://softlibre.gloobe.org</a>_______
> > >__ ___ ___________________________________
> > > Proj mailing list
> > > Proj@lists.maptools.org
> > > <a
> > > href=http://lists.maptools.org/mailman/listinfo/proj>http://lists.mapto
> > >ol s.o rg/mailman/listinfo/proj</a>

-- 
Yves Jacolin
-------------
http://yjacolin.gloobe.org
http://softlibre.gloobe.org

From yjacolin at free.fr  Wed Jun 13 14:25:41 2007
From: yjacolin at free.fr (Yves Jacolin)
Date: Wed Jun 13 14:25:46 2007
Subject: [Proj] Error to convert latlong to lambert2et
In-Reply-To: <170165433214287@lycos-europe.com>
References: <170165433214287@lycos-europe.com>
Message-ID: <200706132025.42121.yjacolin@free.fr>

Hi,

Thanks steberi, you are right ! The complete proj command line is working.

My 27572 code is different from your's (lon_0=0 and some other things). My 
proj version is :
$ proj
Rel. 4.5.0, 22 Oct 2006

Regards,

Y.
PS : sorry for the last mails ;-)

Le Mercredi 13 Juin 2007 15:48, t steberi a ?crit?:
> Hi,
>
> You can check you have this definition in your epsg file:
> # NTF (Paris) / Lambert zone II
> <27572> +proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=2.33722917 +k_0=0.99987742
> +x_0=600000 +y_0=2200000 +a=6378249.2 +b=6356515 +pm=paris +units=m
> +no_defs  no_defs <>
>
> You can also try the explicit command line
> proj +proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=2.33722917 +k_0=0.99987742
> +x_0=600000 +y_0=2200000 +a=6378249.2 +b=6356515 +pm=paris +units=m
> +no_defs -S -r test_file.txt The result (with proj4.5) should be
> 594815.06       2424247.30
>
> Regards,
> Thomas
>
> > De: Jacolin Yves <yjacolin@free.fr>
> > A: proj@lists.maptools.org
> > Objet: [Proj] Error to convert latlong to lambert2et
> > Date: Tue, 12 Jun 2007 10:33:50 +0200
> >
> > Hi,
> >
> > I tried to used proj4 to convert WGS84 data to lambert 2 etendue (french
> > projection, EPSG:27572). Actually, I used a php script that I wrote using
> > an
> > algorithme written in a pdf share by French IGN [1], which is correct.
> >
> > If I try proj4 using the following code:
> > proj +init="epsg:27572" -S -r
> > 48.816667 2.266667
> > 766532.74       2426646.42
> >
> > The new data: (766532.74,2426646.42) is not correct. The first should be
> > something like 594868, the second one seems correct.
> >
> > Where do I may wrong?
> >
> > Regards,
> >
> > Y.
> >
> > [1] <a
> > href=http://www.ign.fr/telechargement/MPro/geodesie/CIRCE/NTG_71.pdf>http
> >:// www.ign.fr/telechargement/MPro/geodesie/CIRCE/NTG_71.pdf</a>--
> > Yves Jacolin
> > ---
> > <a
> > href=http://softlibre.gloobe.org>http://softlibre.gloobe.org</a>_________
> >___ ___________________________________
> > Proj mailing list
> > Proj@lists.maptools.org
> > <a
> > href=http://lists.maptools.org/mailman/listinfo/proj>http://lists.maptool
> >s.o rg/mailman/listinfo/proj</a>

-- 
Yves Jacolin
-------------
http://yjacolin.gloobe.org
http://softlibre.gloobe.org

From fabrice_martin2 at yahoo.fr  Sun Jun 24 13:47:04 2007
From: fabrice_martin2 at yahoo.fr (fabrice martin)
Date: Sun Jun 24 13:47:08 2007
Subject: [Proj] problem in gdalwrap wrt prime meridians
Message-ID: <426788.76677.qm@web26610.mail.ukl.yahoo.com>

Hi,
I'm trying to reproject a geotiff from "lambert 2 etendu" to "lambert 93" (French projections) using gdalwarp from FWTools 1.3.2 under windows XP SP2.
Here is the info concerning the input file.

gdalinfo test.tif

Driver: GTiff/GeoTIFF
Files: test.tif
Size is 2000, 2000
Coordinate System is:
PROJCS["NTF (Paris) / Lambert zone II",
    GEOGCS["NTF (Paris)",
        DATUM["Nouvelle_Triangulation_Francaise_Paris",
            SPHEROID["Clarke 1880 (IGN)",6378249.2,293.4660212936265,
                AUTHORITY["EPSG","7011"]],
            AUTHORITY["EPSG","6807"]],
        PRIMEM["Paris",2.33722917],
        UNIT["degree",0.0174532925199433],
        AUTHORITY["EPSG","4807"]],
    PROJECTION["Lambert_Conformal_Conic_1SP"],
    PARAMETER["latitude_of_origin",46.8],
    PARAMETER["central_meridian",0],
    PARAMETER["scale_factor",0.99987742],
    PARAMETER["false_easting",600000],
    PARAMETER["false_northing",2200000],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AUTHORITY["EPSG","27572"]]
Origin = (827000.000000000000000,2224000.000000000000000)
Pixel Size = (0.500000000000000,-0.500000000000000)
Metadata:
  AREA_OR_POINT=Area
  TIFFTAG_DOCUMENTNAME=39-2006-0820-2221-LA2E07
  TIFFTAG_XRESOLUTION=50.799988
  TIFFTAG_YRESOLUTION=50.799988
  TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch)
Corner Coordinates:
Upper Left  (  827000.000, 2224000.000) (  2d59'3.48"E, 46d58'37.71"N)
Lower Left  (  827000.000, 2223000.000) (  2d59'1.68"E, 46d58'5.34"N)
Upper Right (  828000.000, 2224000.000) (  2d59'50.76"E, 46d58'36.47"N)
Lower Right (  828000.000, 2223000.000) (  2d59'48.96"E, 46d58'4.11"N)
Center      (  827500.000, 2223500.000) (  2d59'26.22"E, 46d58'20.91"N)
Band 1 Block=2000x4 Type=Byte, ColorInterp=Red
Band 2 Block=2000x4 Type=Byte, ColorInterp=Green
Band 3 Block=2000x4 Type=Byte, ColorInterp=Blue


I try to reproject this image using the following command, giving the input projection system with a string being the exact copy of the EPSG definition for code 27572:

D:\>gdalwarp -s_srs "+proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0
+k_0=0.99987742 +x_0=600000 +y_0=2200000 +a=6378249.2 +b=6356515 +towgs84=-168,-
60,320,0,0,0,0 +pm=paris +units=m +no_defs" -t_srs "+init=epsg:2154" -tps -rc -tr
 0.5 0.5 -co INTERLEAVE=PIXEL test.tif test_res.tif


D:\>gdalinfo test_res.tif
Driver: GTiff/GeoTIFF
Files: test_res.tif
Size is 2040, 2040
Coordinate System is:
PROJCS["RGF93 / Lambert-93",
    GEOGCS["RGF93",
        DATUM["Reseau_Geodesique_Francais_1993",
            SPHEROID["GRS 1980",6378137,298.2572221010002,
                AUTHORITY["EPSG","7019"]],
            AUTHORITY["EPSG","6171"]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433],
        AUTHORITY["EPSG","4171"]],
    PROJECTION["Lambert_Conformal_Conic_2SP"],
    PARAMETER["standard_parallel_1",49],
    PARAMETER["standard_parallel_2",44],
    PARAMETER["latitude_of_origin",46.5],
    PARAMETER["central_meridian",3],
    PARAMETER["false_easting",700000],
    PARAMETER["false_northing",6600000],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AUTHORITY["EPSG","2154"]]
Origin = (1053910.241789964700000,6663452.274245270500000)
Pixel Size = (0.500000000000000,-0.500000000000000)
Metadata:
  AREA_OR_POINT=Area
Corner Coordinates:
Upper Left  ( 1053910.242, 6663452.274) (  7d39'29.83"E, 46d58'38.29"N)
Lower Left  ( 1053910.242, 6662432.274) (  7d39'26.99"E, 46d58'5.29"N)
Upper Right ( 1054930.242, 6663452.274) (  7d40'18.05"E, 46d58'36.34"N)
Lower Right ( 1054930.242, 6662432.274) (  7d40'15.20"E, 46d58'3.34"N)
Center      ( 1054420.242, 6662942.274) (  7d39'52.52"E, 46d58'20.82"N)
Band 1 Block=2040x1 Type=Byte, ColorInterp=Red
Band 2 Block=2040x1 Type=Byte, ColorInterp=Green
Band 3 Block=2040x1 Type=Byte, ColorInterp=Blue
Creating output file that is 2040P x 2040L.
Processing input file test.tif.
:0...10...20...30...40...50...60...70...80...90...100 - done.


As one can see, the upper left corner is shifted ~ 2,3? east. The result should be near 5d19' and not 7d39'. It looks as if the prime meridian has been accounted for twice. This is incoherent with cs2cs, which gives the right result:

D:\>cs2cs -v +init=epsg:27572 +to +init=epsg:2154
# ---- From Coordinate System ----
#Lambert Conformal Conic
#       Conic, Sph&Ell
#       lat_1= and lat_2= or lat_0
# +init=epsg:27572 +proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0 +k_0=0.99987742
# +x_0=600000 +y_0=2200000 +a=6378249.2 +b=6356515
# +towgs84=-168,-60,320,0,0,0,0 +pm=paris +units=m +no_defs
# ---- To Coordinate System ----
#Lambert Conformal Conic
#       Conic, Sph&Ell
#       lat_1= and lat_2= or lat_0
# +init=epsg:2154 +proj=lcc +lat_1=49 +lat_2=44 +lat_0=46.5 +lon_0=3
# +x_0=700000 +y_0=6600000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
# +no_defs
827000 2224000
876410.07       6655580.63 41.71

In addition, it seems that gdalwarp "knows" an internal definition of EPSG codes giving the right results:

D:\>gdalwarp -s_srs EPSG:27572 -t_srs "+init=epsg:2154" -tps -rc
 -tr 0.5 0.5 -co INTERLEAVE=PIXEL test.tif test_res2.tif
Creating output file that is 2015P x 2015L.
Processing input file test.tif.
:0...10...20...30...40...50...60...70...80...90...100 - done.

D:\dalles_lambert93>gdalinfo test_res2.tif
Driver: GTiff/GeoTIFF
Files: test_res2.tif
Size is 2015, 2015
Coordinate System is:
PROJCS["RGF93 / Lambert-93",
    GEOGCS["RGF93",
        DATUM["Reseau_Geodesique_Francais_1993",
            SPHEROID["GRS 1980",6378137,298.2572221010002,
                AUTHORITY["EPSG","7019"]],
            AUTHORITY["EPSG","6171"]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433],
        AUTHORITY["EPSG","4171"]],
    PROJECTION["Lambert_Conformal_Conic_2SP"],
    PARAMETER["standard_parallel_1",49],
    PARAMETER["standard_parallel_2",44],
    PARAMETER["latitude_of_origin",46.5],
    PARAMETER["central_meridian",3],
    PARAMETER["false_easting",700000],
    PARAMETER["false_northing",6600000],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AUTHORITY["EPSG","2154"]]
Origin = (876401.507783832840000,6655580.627617656300000)
Pixel Size = (0.500000000000000,-0.500000000000000)
Metadata:
  AREA_OR_POINT=Area
Corner Coordinates:
Upper Left  (  876401.508, 6655580.628) (  5d19'15.01"E, 46d58'37.58"N)
Lower Left  (  876401.508, 6654573.128) (  5d19'13.61"E, 46d58'4.94"N)
Upper Right (  877409.008, 6655580.628) (  5d20'2.70"E, 46d58'36.62"N)
Lower Right (  877409.008, 6654573.128) (  5d20'1.29"E, 46d58'3.98"N)
Center      (  876905.258, 6655076.878) (  5d19'38.15"E, 46d58'20.78"N)
Band 1 Block=2015x1 Type=Byte, ColorInterp=Red
Band 2 Block=2015x1 Type=Byte, ColorInterp=Green
Band 3 Block=2015x1 Type=Byte, ColorInterp=Blue

However, this is not a solution, as I would like to use my own definitions for projections (I want to use nadgrids for French projections)...

There's definitely a big problem here, don't you think so ?

Best regards,
Fabrice.




      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail 

From fabrice_martin2 at yahoo.fr  Mon Jun 25 17:31:16 2007
From: fabrice_martin2 at yahoo.fr (fabrice martin)
Date: Mon Jun 25 17:31:23 2007
Subject: [Proj] problem in gdalwrap wrt prime meridians
Message-ID: <540516.84433.qm@web26610.mail.ukl.yahoo.com>

Hi, I think I've narrowed the problem:

Instead of trying:

D:\>gdalwarp -s_srs "+proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0
+k_0=0.99987742 +x_0=600000 +y_0=2200000 +a=6378249.2 +b=6356515 +towgs84=-168,-
60,320,0,0,0,0 +pm=paris +units=m +no_defs" -t_srs "+init=epsg:2154" -tps -rc -tr
 0.5 0.5 -co INTERLEAVE=PIXEL test.tif test_res.tif

I tried:
D:\>gdalwarp -s_srs "+proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=2.33722917
+k_0=0.99987742 +x_0=600000 +y_0=2200000 +a=6378249.2 +b=6356515 +towgs84=-168,-
60,320,0,0,0,0  +units=m +no_defs" -t_srs "+init=epsg:2154" -tps -rc -tr
 0.5 0.5 -co INTERLEAVE=PIXEL test.tif test_res3.tif

where 2.33722917 is the prime meridian of paris.

The two formulations should be strictly equivalent, however the second one gives the right result:

D:\>gdalinfo test_res3.tif

Corner Coordinates:
Upper Left  (  876401.508, 6655580.628) (  5d19'15.01"E, 46d58'37.58"N)
Lower Left  (  876401.508, 6654573.128) (  5d19'13.61"E, 46d58'4.94"N)
Upper Right (  877409.008, 6655580.628) (  5d20'2.70"E, 46d58'36.62"N)
Lower Right (  877409.008, 6654573.128) (  5d20'1.29"E, 46d58'3.98"N)
Center      (  876905.258, 6655076.878) (  5d19'38.15"E, 46d58'20.78"N)
Band 1 Block=2015x1 Type=Byte, ColorInterp=Red
Band 2 Block=2015x1 Type=Byte, ColorInterp=Green
Band 3 Block=2015x1 Type=Byte, ColorInterp=Blue


Thus, there's definitely a problem related to the prime meridian +pm, which seems to be added twice (maybe it is added once to +lon_0 and another time it is taken into account with the +pm value ??)

Best regards,
Fabrice.




      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail 
From gheysen.t at gmail.com  Tue Jun 26 04:16:24 2007
From: gheysen.t at gmail.com (Thibaut Gheysen)
Date: Tue Jun 26 04:17:32 2007
Subject: [Proj] Garbel - software for GPS data management
Message-ID: <94e91cde0706260116y5d54ba7bv1058791000b2abe7@mail.gmail.com>

Hello,

I have developed a little software named Garbel for GPS data management
(waypoints, track and roads) of Garmin(r) and Magellan(r) GPS receiver
making it
possible to manage transfers PC - GPS as well as the possibles
transformations of coordinates which result from it. For this, I use this
utilities and libraries : GpsBabel, PROJ.4, GDAL/OGR and shp2img.

This software is freeware but only available in French. I have plan to add
other languages but I miss time to do this for the moment. You can download
it from the website of the Unit of Forest and Nature Management of the
Gembloux Agricultural University ( http://www.fsagx.ac.be/gf/) at the
heading ? tools and software ? (? Outils et logiciels ?)

Best regards,
Thibaut.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20070626/f1122556/attachment.html
From j.l.h.hartmann at uva.nl  Tue Jun 26 12:36:34 2007
From: j.l.h.hartmann at uva.nl (Jan Hartmann)
Date: Tue Jun 26 12:36:31 2007
Subject: [Proj] Garbel - software for GPS data management
In-Reply-To: <94e91cde0706260116y5d54ba7bv1058791000b2abe7@mail.gmail.com>
References: <94e91cde0706260116y5d54ba7bv1058791000b2abe7@mail.gmail.com>
Message-ID: <46814092.4060702@uva.nl>

Bonjour Thibaut, very nice, thanks!

Jan



Thibaut Gheysen wrote:
> Hello,
> 
> I have developed a little software named Garbel for GPS data management 
> (waypoints, track and roads) of Garmin? and Magellan? GPS receiver 
> making it possible to manage transfers PC - GPS as well as the possibles 
> transformations of coordinates which result from it. For this, I use 
> this utilities and libraries : GpsBabel, PROJ.4, GDAL/OGR and shp2img.
> 
> This software is freeware but only available in French. I have plan to 
> add other languages but I miss time to do this for the moment. You can 
> download it from the website of the Unit of Forest and Nature Management 
> of the Gembloux Agricultural University ( http://www.fsagx.ac.be/gf/) at 
> the heading ? tools and software ? (? Outils et logiciels ?)
> 
> Best regards,
> Thibaut.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Proj mailing list
> Proj@lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj