[PROJ] Behavior of proj_create_crs_to_crs() when using +proj=utm format

[José Luis García Pallero]

El mar, 26 oct 2021 a las 16:45, Even Rouault
(<even.rouault at spatialys.com>) escribió:
>
> Hi,
>
> it is a bit tricky.
>
> wen you use proj_create() with a PROJ string without +type=crs, it goes (almost) directly through the "historic" code of PROJ, which interprets its as a coordinate transformation string, and I indeed discover by looking at it that it accepts +lon_0 as an alternative to +zone (but if you don't specify something that is an expected longitude of natural origin for UTM, then it will round to the closest without warning...). But https://proj.org/operations/projections/utm.html only documents +utm as a required parameter, so that is a bit of a chance that it works.
>
> When you use proj_create_crs_to_crs(), PROJ strings are interpretated as CRS, which goes to a different code path, and that code path enforces that +zone is specified, now to a valid value.
>
> Regarding error messages, yeah, this is a bit tricky and linked to the interaction of the C and C++ parts of the code. Basically the "Invalid zone number" is emitted as a C++ exception without a specific C error code, then it is caught by proj_create() which emits it as a logged error (proj_create() is called by proj_create_crs_to_crs()), and the generic PROJ_ERR_OTHER=4096 is set because the code that catch the C++ exception has no better hint.

Thanks for your complete answer, Even. Only for curiosity (and without
any criticism), why PROJ moved part of the code from the beautiful and
practical C language to the ugly C++? I hope at least the C interface
will be forever maintained.

>
> Even
>
> Le 26/10/2021 à 16:27, José Luis García Pallero a écrit :
>
> Hello:
>
> I'm using PROJ 8.1.1 from the Debian Sid repositories, and I'm having
> troubles with proj_create_crs_to_crs() using a code that worked
> without problems with PROJ 7.2.1.
>
> My example, attached as tproj.c projects a point from (lat,lon) onto
> the UTM zone 30 plane. I use the proj_trans_generic() function, but in
> a first case I define the projection using the proj_create() function
> with parameters "+proj=utm +lon_0=3w +ellps=GRS80". In this case all
> works fine, as the UTM zone 30 is defined but its central meridian
> +lon_0=3w.
>
> But in my second example I define a transformation between CRSs using
> the function proj_create_crs_to_crs(), and the parameter strings
> "+proj=latlong +ellps=GRS80" and "+proj=utm +lon_0=3w +ellps=GRS80",
> and the problem comes with +lon_0=3w. I need to define the parameter
> string as "+proj=utm +zone=30 +ellps=GRS80", case in which all works
> well. But why proj_create_crs_to_crs() works with +zone=30 and fails
> with +lon_0=3w if both definitions are equivalent for the UTM, and it
> works using proj_create()?
>
> Also the error string created with proj_errno_string() is confusing,
> as it returns "Unknown error (code 4096)", but at the same the string
> "proj_create: Invalid zone number" is printed on screen. I think this
> last message will be returned by proj_errno_string(). Also, in this
> string proj_create() is referred instead of proj_create_crs_to_crs().
>
> Attached I send the code
>
> Thanks
>
>
> _______________________________________________
> 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



-- 
*****************************************
José Luis García Pallero
jgpallero at gmail.com
(o<
/ / \
V_/_
Use Debian GNU/Linux and enjoy!
*****************************************