[gdal-dev] GDAL 3.3.0beta1 available

[Even Rouault]

Greg,

There's a high chance for this to be completely PROJ behavior. GDAL 
hardly knows about CRS those days :-)

Could you share your input and output files ?

Also set CPL_DEBUG=PROJ and PROJ_DEBUG=2 as environment variables to see 
which transformations PROJ pickup : look for lines starting with "PROJ: 
Using coordinate operation ..."

With latest PROJ master (and also 6.3.2), I see that

projinfo -s EPSG:6319 -t EPSG:7912 -o PROJ

Candidate operations found: 1
-------------------------------------
Operation No. 1:

unknown id, Conversion from NAD83(2011) (geog3D) to NAD83(2011) 
(geocentric) + Inverse of ITRF2014 to NAD83(2011) (1) + Conversion from 
ITRF2014 (geocentric) to ITRF2014 (geog3D), 0 m, Puerto Rico - onshore 
and offshore. United States (USA) onshore and offshore - Alabama; 
Alaska; Arizona; Arkansas; California; Colorado; Connecticut; Delaware; 
Florida; Georgia; Idaho; Illinois; Indiana; Iowa; Kansas; Kentucky; 
Louisiana; Maine; Maryland; Massachusetts; Michigan; Minnesota; 
Mississippi; Missouri; Montana; Nebraska; Nevada; New Hampshire; New 
Jersey; New Mexico; New York; North Carolina; North Dakota; Ohio; 
Oklahoma; Oregon; Pennsylvania; Rhode Island; South Carolina; South 
Dakota; Tennessee; Texas; Utah; Vermont; Virginia; Washington; West 
Virginia; Wisconsin; Wyoming. US Virgin Islands - onshore and offshore.

PROJ string:
+proj=pipeline
   +step +proj=axisswap +order=2,1
   +step +proj=unitconvert +xy_in=deg +z_in=m +xy_out=rad +z_out=m
   +step +proj=cart +ellps=GRS80
   +step +inv +proj=helmert +x=1.0053 +y=-1.9092 +z=-0.5416 +rx=0.0267814
         +ry=-0.0004203 +rz=0.0109321 +s=0.00037 +dx=0.0008 +dy=-0.0006
         +dz=-0.0014 +drx=6.67e-05 +dry=-0.0007574 +drz=-5.13e-05 +ds=-7e-05
         +t_epoch=2010 +convention=coordinate_frame
   +step +inv +proj=cart +ellps=GRS80
   +step +proj=unitconvert +xy_in=rad +z_in=m +xy_out=deg +z_out=m
   +step +proj=axisswap +order=2,1

So it applies a time-dependent Helmert transformation, which has also 
non-time dependent terms.

However trying a bit, the transformation seems to introduce a shift of 
about ~1 m or so, not 35 m

$ echo 50 -100 0 | cs2cs -d 8 EPSG:6319 EPSG:7912
50.00000754    -100.00001400 -0.68652183

$ echo 50 -100 50.00000754 -100.00001400 | geod -I +ellps=GRS80
-50d7'11.377"    129d52'48.584"    1.308

Even

Le 24/04/2021 à 16:39, Greg Troxel a écrit :
> Even Rouault <even.rouault at spatialys.com> writes:
>
>> - http://download.osgeo.org/gdal/3.3.0/gdal-3.3.0beta1.tar.gz
> The tl;dr is:
>
>    - I'm seeing bad transforms NAD83/ITRF with 3.3.0beta1 but I do not
>      have any basis to blame 3.3.0 because a lot of other things are in
>      flux.
>
>    - If you are using 3.3.0beta1 and transforms I suggest looking at your
>      output data.
>
>
>
> I have noticed a problem but I have little idea where it is.  I will be
> looking into it myself but I wanted to mention it so that others could
> be on the lookout.
>
> Besides updating to gdal, I'm doing a general software freshening and
> rebuilding lots of things, but aside from the gdal beta my geo packages
> haven't changed versions.  I have proj 6.3.2 with installed grids, which
> was just rebuilt.
>
> The background is that I'm mostly working in EPSG:6319 which is
> NAD83(2011).
>
> I transform to EPSG:7912 which is ITRF2014 to display the data on
> leaflet webmaps (as a proxy for WGS84 to avoid null transforms).
>
> I noticed that my points on the webmap were very far off, displaced very
> roughly 35m ESE.  I then put an NAD83 version in the webspace, and that
> made things look ok (with the ~1 meter error from treating NAD83 and
> ITRF2014 as equal, surely).
>
> I'm extracting things from a geopackage in 6319 like
>
>      ogr2ogr -f GeoJSON -t_srs "EPSG:7912" -s_srs "EPSG:6319" FOO/issues.geojson foo.gpkg issues
>      ogr2ogr -f GeoJSON -t_srs "EPSG:6319" -s_srs "EPSG:6319" FOO/issues-nad83.geojson foo.gpkg issues
>
> which has previously been fine.  I'm definitely getting very large
> offsets from two files extracted seconds apart from the very same
> geopackage.
>
> So this is not a request for help, but if you are using ogr2ogr to
> transform datums, and you are using gdal 3.3.0beta1 especially with proj
> 6, I'd suggest a quick look at your output data to see if it seems ok.
>
> I will be retesting after all the software rebuilds are done, and
> rolling back to released gdal.  (Yes, I know proj 6.3 is old and that I
> should update.)
>
> Thanks,
> Greg

-- 
http://www.spatialys.com
My software is free, but my time generally not.