Hi Even,
I'm testing this fix on PROJ 8.2.0, but I'm getting the same output than
before the fix:
C:\OSGeo4W>gdaltransform -s_srs EPSG:20790 -t_srs EPSG:3763
Enter X Y [Z [T]] values separated by space, and press Return.
286415 431434
86412.5265012686 131433.856093867 0
C:\OSGeo4W>gdalinfo --ver
>
> So, the default will be the use of the operation with better accuracy,
> right?
>
> yes, due to the issue with the prime meridian, PROJ was confused and
> didn't find any valid operation with the appropriate area of use, and thus
> it fell back to an operation not using a grid
>
Perfect, thank
Le 06/10/2021 à 01:26, Pedro Venâncio a écrit :
What a supersonic fix Even, thank you very much!!
So, the default will be the use of the operation with better accuracy,
right?
yes, due to the issue with the prime meridian, PROJ was confused and
didn't find any valid operation with the appro
What a supersonic fix Even, thank you very much!!
So, the default will be the use of the operation with better accuracy,
right?
Thanks Even!
Pedro
Even Rouault escreveu no dia quarta, 6/10/2021
à(s) 00:06:
> This is a PROJ >= 7.2 bug, related to CRS with non-Greenwich prime
> meridian. Fix
This is a PROJ >= 7.2 bug, related to CRS with non-Greenwich prime
meridian. Fix in https://github.com/OSGeo/PROJ/pull/2884
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osg
Hi all,
I'm trying to understand what is the transformation used by default by
GDAL/OGR.
For instance, the transformation from EPSG:20790 to EPSG:3763 has two
candidates on PROJ:
C:\OSGeo4W>projinfo -s EPSG:20790 -t EPSG:3763
Candidate operations found: 2
-
Op
