[gdal-dev] Relation between PROJ8, GDAL, and national grids

[Even Rouault]

Juan Pedro,

the fact that the es_ign_SPED2ETV2.tif grid wasn't used turned out to be 
a PROJ issue, with a fix now queued in 
https://github.com/OSGeo/PROJ/pull/2619

One easy workaround is that you create symbol links:

ln -s es_ign_SPED2ETV2.tif /usr/local/share/proj/PENR2009.gsb

ln -s es_ign_SPED2ETV2.tif /usr/local/share/proj/BALR2009.gsb

Regarding the differences in output between gdaltransform and cs2cs, 
this is just different rounding modes of the floating point values. You 
can change the number of decimals of cs2cs with the -d 
{number_of_decimals} switch

Even

Le 28/03/2021 à 19:57, Juan Pedro Pérez Alcántara a écrit :
> Even, thanks for replying, and Javier, thanks for the advice about the 
> list etiquette. I will not change the subject in such events.
>
> I'm sure it's the only PROJ installation because I'm building the 
> libraries in a Docker container. I've also conducted some more tests 
> from zero, I've found out I've been using some old tests I wrote some 
> time ago that were outdated and faulty, sorry about that. What follows 
> is the detailed actions I've taken.
>
> With the IGN (Spanish National Geographic Institute) geodesic 
> calculator I performed a EPSG 23030 (ED50 UTM 30N) to EPSG 25830 
> (ETRS89 UTM 30N) shift:
>
> 235205.243 4142110.093  >  235094 4141906
>
> I take this as the target result.
>
> I set PROJ_LIB to /usr/local/share/proj and configured PROJ with a 
> simple ./configure, no options.
>
> Using cs2cs:
>
> cs2cs EPSG:23030 EPSG:25830 > 235094.09 4141905.02
>
> which I suppose is a 7 parameters shift, which is great, but not 
> perfect, can do better with the grid. Thus:
>
> cs2cs +proj=utm +zone=30 +ellps=intl +units=m +no_defs 
> +nadgrids=/usr/local/share/proj/es_ign_SPED2ETV2.tif +to EPSG:25830 > 
> 235094.00 4141906.00
>
> which nails it. Again, my fault assuming PROJ was using the grid by 
> default.
>
> Then I compiled GDAL with another flat ./configure, it found a PROJ >= 
> 6. Using gdaltransform:
>
> gdaltransform -s_srs EPSG:23030 -t_srs EPSG:25830 > 235094.087184815 
> 4141905.01683498
>
> which is consistent with cs2cs. Using:
>
> gdaltransform -s_srs "+proj=utm +zone=30 +ellps=intl +units=m +no_defs 
> +nadgrids=/usr/local/share/proj/es_ign_SPED2ETV2.tif" -t_srs 
> EPSG:25830 > 235094.000297496 4141905.99963473
>
> which is consistent with cs2cs too.
>
> Then, having solved this part of the issue, I would like very much if 
> you can advice me on how to "tweak" default definitions of the SRS to 
> include the use of the grid by default, which would be not absolutely 
> necessary for my application but a nice to have.
>
> Also, just out of curiosity, why are PROJ and GDAL yielding slightly 
> different outputs (albeit perfectly ok both)? Is GDAL doing its own 
> calculations besides PROJ? Forgive my lack of deep understanding of 
> the GDAL inner architecture for I am an end user and not a developer. 
> Just curious.
>
>
> Best regards,
>
> ---
>
> Juan Pedro Pérez Alcántara
>
> jp.perez.alcantara at gmail.com <mailto:jp.perez.alcantara at gmail.com>
>
>
>
> On Sat, 27 Mar 2021 at 21:32, Even Rouault <even.rouault at spatialys.com 
> <mailto:even.rouault at spatialys.com>> wrote:
>
>     Juan Pedro,
>
>
>     >
>     > I'm at a loss trying to understand the relationship between PROJ8,
>     > GDAL, and how to use TIFF national grids. So far my findings are:
>     >
>     > - PROJ8 is installed and cs2cs uses the grid to transform,
>     performing
>     > an extremely accurate shift;
>     >
>     > - GDAL, compile on the above PROJ8, when using
>     > gdaltransform, yields less accurate
>
>     There's no fundamental reason for transforms with gdaltransform being
>     less accurate than with cs2cs. You have to be much more specific with
>     the exact gdaltransform invokation you are trying. And are you really
>     sure that you use the PROJ version you think ? (check with ldd
>     libgdal.so on Linux)
>
>     You can also set the PROJ_DEBUG=2 and CPL_DEBUG=ON environment
>     variables
>     and look at the traces.
>
>     Even
>
>
>     -- 
>     http://www.spatialys.com <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/gdal-dev/attachments/20210328/5b7c26e5/attachment.html>