[PROJ] Migrating to PROJ-9

Even Rouault even.rouault at spatialys.com
Tue May 30 11:02:20 PDT 2023


It should work at least with the API using proj_factors() since PROJ 
8.2. Cf https://github.com/OSGeo/PROJ/pull/2868 (you should likely strip 
off the +init= prefix then)

Le 30/05/2023 à 19:56, Nicolas Bellaiche a écrit :
> Ok i hoped your answer would help me understanding why I can't compute 
> the scale factor properly but unfortunately it doesn't give me any idea.
> If I instantiate a PJ* with the new syntax (with proj_create), the 
> meridional_scale is not computed correctly with proj_factors, while 
> with the old "+init=" it still works.
> N.
>
>
> ------------------------------------------------------------------------
> *De: *"Even Rouault" <even.rouault at spatialys.com>
> *À: *"Nicolas Bellaiche" <nicolas.bellaiche at ign.fr>
> *Cc: *"proj" <proj at lists.osgeo.org>
> *Envoyé: *Mardi 30 Mai 2023 19:48:17
> *Objet: *Re: [PROJ] Migrating to PROJ-9
>
>
> Le 30/05/2023 à 19:24, Nicolas Bellaiche a écrit :
>
>
>     Ok, i kind of fixed my issue even if that's not all very clear to me.
>     One of the things that I can't understand is that outdated "+init="
>
>     For instance if I try to use
>
>     echo 2d20\'11.5\"E46d47\'59.775\"N |./bin/projIGNF:LAMBE -Swithout
>     the +init= syntaxI get
>
>
>     proj_create: unrecognized format / unknown name
>
>     Rel. 9.1.1, December 1st, 2022
>
>     <proj>:
>
>     projection initialization failure
>
>     cause: Invalid PROJ string syntax
>
>     program abnormally terminated
>
>
>     Is it normal?
>
> Maybe? the old proj utility works with coordinate operations, actually 
> only map projections, but not CRS definitions. In PROJ 4.x era, there 
> was no such distinction. IGNF:LAMBE is a CRS definition now. 
> Furthermore the proj utility has not been updated to resolve objects 
> by code/names. (with the +init= prefix, proj errors out with "can't 
> initialize operations that take non-angular input coordinates" for me. 
> likely some mismatch between radian vs degree input expectations). I 
> presume it could be enhanced to work with projected CRS definitions, 
> although it is not totally clear to me what should be the expectations 
> regarding input/output axis order.
>
> Even
>
>
>     Sincerely,
>
>
>     N.B.
>
>
>     ------------------------------------------------------------------------
>     *De: *"Even Rouault" <even.rouault at spatialys.com>
>     <mailto:even.rouault at spatialys.com>
>     *À: *"Nicolas Bellaiche" <nicolas.bellaiche at ign.fr>
>     <mailto:nicolas.bellaiche at ign.fr>
>     *Cc: *"proj" <proj at lists.osgeo.org> <mailto:proj at lists.osgeo.org>
>     *Envoyé: *Mardi 30 Mai 2023 14:43:03
>     *Objet: *Re: [PROJ] Migrating to PROJ-9
>
>     Weird indeed:
>
>     and what about trying directly the pipeline with cct :
>
>     echo 652760.73700000 7033791.24300000 43.64200000 | cct
>     +proj=pipeline +step +inv +proj=lcc +lat_0=46.5 +lon_0=3 +lat_1=44
>     +lat_2=49 +x_0=700000 +y_0=6600000 +ellps=GRS80 +step +proj=cart
>     +ellps=GRS80
>
>     you should get:
>
>      4070327.2514    166078.9321  4891298.6149 inf
>
>     Le 30/05/2023 à 14:35, Nicolas Bellaiche a écrit :
>
>         Bonjour M. Rouault,
>
>         *
>         *
>
>         Voilà ce que j'obtiens:
>
>         *
>         *
>
>         *PROJ9:*
>
>         *
>         *
>
>         *Release % PROJ_DEBUG=3 projinfo -s IGNF:LAMB93 -t IGNF:RGF93
>         -o PROJ*
>
>
>
>         pj_open_lib(proj.ini): call
>         fopen(/Users/nbellaiche/dev/sd-externs/macosx-clang/proj-9.1.1/nad/proj.ini)
>         - succeeded
>
>         pj_open_lib(proj.db): call
>         fopen(/Users/nbellaiche/dev/sd-externs/macosx-clang/proj-9.1.1/nad/proj.db)
>         - succeeded
>
>         Candidate operations found: 1
>
>         -------------------------------------
>
>         Operation No. 1:
>
>
>         unknown id, Inverse of LAMBERT-93 + Conversion from RGF93
>         geographiques (dms) to RGF93 cartesiennes geocentriques, 0 m,
>         World
>
>
>         PROJ string:
>
>         +proj=pipeline
>
>         +step +inv +proj=lcc +lat_0=46.5 +lon_0=3 +lat_1=44 +lat_2=49
>         +x_0=700000
>
>         +y_0=6600000 +ellps=GRS80
>
>         +step +proj=cart +ellps=GRS80
>
>
>
>         * Release % echo 652760.73700000 7033791.24300000 43.64200000
>         | cs2cs +init=IGNF:LAMB93 +to +init=IGNF:RGF93*
>
>         4070355.05166080.07 4891332.24
>
>
>
>         * Release % echo $PROJ_DATA*
>
>         /Users/nbellaiche/dev/sd-externs/macosx-clang/proj-9.1.1/nad
>
>
>         * Release % echo $PROJ_LIB*
>
>         /Users/nbellaiche/dev/sd-externs/macosx-clang/proj-9.1.1/nad
>
>
>
>         je ne vois pas de différence. Je n'ai pas le début d'une idée
>         de comment identifier le problème...
>
>
>         N.
>
>
>
>
>         ------------------------------------------------------------------------
>         *De: *"Even Rouault" <even.rouault at spatialys.com>
>         <mailto:even.rouault at spatialys.com>
>         *À: *"proj" <proj at lists.osgeo.org> <mailto:proj at lists.osgeo.org>
>         *Envoyé: *Vendredi 26 Mai 2023 21:50:27
>         *Objet: *Re: [PROJ] Migrating to PROJ-9
>
>         Ah, and you should avoid using the "+init=" prefix. This is a
>         deprecated legacy syntax that doesn't enforce axis order of
>         the CRS definition (without practical consequence for IGNF:
>         CRS since they use "GIS friendly" axis order)
>
>         To help debugging this, please provide the output of:
>
>         PROJ_DEBUG=3 projinfo -s IGNF:LAMB93 -t IGNF:RGF93 -o PROJ
>
>         On my system I get:
>
>         pj_open_lib(proj.ini): call
>         fopen(/home/even/proj/install-proj-master/share/proj/proj.ini)
>         - succeeded
>         pj_open_lib(proj.db): call
>         fopen(/home/even/proj/install-proj-master/share/proj/proj.db)
>         - succeeded
>         Candidate operations found: 1
>         -------------------------------------
>         Operation No. 1:
>
>         unknown id, Inverse of LAMBERT-93 + Conversion from RGF93
>         geographiques (dms) to RGF93 cartesiennes geocentriques, 0 m,
>         World
>
>         PROJ string:
>         +proj=pipeline
>           +step +inv +proj=lcc +lat_0=46.5 +lon_0=3 +lat_1=44
>         +lat_2=49 +x_0=700000
>                 +y_0=6600000 +ellps=GRS80
>           +step +proj=cart +ellps=GRS80
>
>         Le 26/05/2023 à 21:46, Even Rouault a écrit :
>
>             Hi,
>
>             I get the expected 4070327.25 166078.93 4891298.61 result
>             with proj 6.0.0, 7.2.1, 9.2.0 and master
>
>             There's no grid involved in this operation, just inverse
>             LCC projection on the RGF93 datum
>
>             I also tried to reproduce your issue if the PROJ < 6 IGNF
>             file is found in the PROJ resource path(s) (non nominal
>             situation - this file is not needed any more, and will
>             generally lead to suboptimal results. Its content is
>             included in the proj.db file), but even with that I get
>             the expected result. So no idea why you get wrong results
>
>             Even
>
>
>             Le 26/05/2023 à 20:54, Nicolas Bellaiche a écrit :
>
>                 Hi all,
>
>                 I'm migrating my C++ code from PROJ4 to PROJ9 and I
>                 meet a worrying issue with the computation. Some of my
>                 regress tests don't pass so I've tested with cs2cs and
>                 gets the same difference:
>
>                 PROJ4
>
>                 echo652760.737000007033791.24300000 43.64200000 |
>                 cs2cs +init=IGNF:LAMB93 +to +init=IGNF:RGF93:
>
>                 4070327.25166078.93 4891298.61
>
>
>                 PROJ7 or PROJ9
>
>                 echo652760.737000007033791.24300000 43.64200000 |
>                 cs2cs +init=IGNF:LAMB93 +to +init=IGNF:RGF93:
>
>                 4070355.05166080.07 4891332.24
>
>
>
>
>                 I suspect that PROJ7 and PROJ9 don't read properly the
>                 geoid file but I'm not sure. Someone can help me
>                 tracking and fixing this problem?
>
>                 Thanks,
>
>                 Nicolas Bellaiche
>                 Institut Géographique National France
>
>                 _______________________________________________
>                 PROJ mailing list
>                 PROJ at lists.osgeo.org
>                 https://lists.osgeo.org/mailman/listinfo/proj
>
>             -- 
>             http://www.spatialys.com
>             My software is free, but my time generally not.
>
>
>             _______________________________________________
>             PROJ mailing list
>             PROJ at lists.osgeo.org
>             https://lists.osgeo.org/mailman/listinfo/proj
>
>         -- 
>         http://www.spatialys.com
>         My software is free, but my time generally not.
>
>
>         _______________________________________________
>         PROJ mailing list
>         PROJ at lists.osgeo.org
>         https://lists.osgeo.org/mailman/listinfo/proj
>
>     -- 
>     http://www.spatialys.com
>     My software is free, but my time generally not.
>
>
> -- 
> http://www.spatialys.com
> My software is free, but my time generally not.
>
-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20230530/7ed64201/attachment-0001.htm>


More information about the PROJ mailing list