<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>oh.... so I was wrong and you've spotted the reason for what Greg
notices. So this is (was) a GDAL 3.3 specific bug (3.2 is fine). <br>
</p>
<p>GDAL should have passed HUGE_VAL when no explicit time is
specified, which would be interpreted by PROJ as ignoring the
time-dependent parts (or equivalently using the reference epoch of
the transformation, which nullifies the effect of those
time-dependent parts), but it incorrectly passes 0 currently</p>
<p>Transformation at epoch 0:<br>
</p>
<p>$ echo 100 -50 0 0 | gdaltransform -s_srs EPSG:6319 -t_srs
EPSG:7912 <br>
100.000520678775 -49.9999650963593 1.20454746671021</p>
<p>==> ~ 100 m shift</p>
<p>Transformation at epoch 2010;<br>
</p>
<p>$ echo 100 -50 0 2010 | gdaltransform -s_srs EPSG:6319 -t_srs
EPSG:7912 <br>
100.00001055598 -49.9999754213041 0.900845746509731</p>
<p>Current incorrect behavior is the same as at epoch 0<br>
</p>
<p>$ echo 100 -50 | gdaltransform -s_srs EPSG:6319 -t_srs EPSG:7912
<br>
100.000520678775 -49.9999650963593 1.20454746671021 <br>
</p>
<p>With fix queued in <a class="moz-txt-link-freetext" href="https://github.com/OSGeo/gdal/pull/3738">https://github.com/OSGeo/gdal/pull/3738</a><br>
</p>
<p>we now get the same as epoch 2010<br>
</p>
<p>$ echo 100 -50 | gdaltransform -s_srs EPSG:6319 -t_srs EPSG:7912
<br>
100.00001055598 -49.9999754213041 0.900845746509731</p>
<p>Even<br>
</p>
<div class="moz-cite-prefix">Le 24/04/2021 à 17:13, Javier Jimenez
Shaw a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CADRrdKv84QbbYFWanAE4QoYsrEzu8gxKTZZ4QoYpEcpgQn=vVA@mail.gmail.com">
<div dir="ltr">
<div>Just one idea: which time is setting GDAL (and/or PROJ
understanding) on the transformation if nothing is specified?
Is it the same as in cs2cs?</div>
<div>That transformation is time dependent.</div>
<div>I read somewhere that the "default" value is not the same
(but my memory is not very reliable).</div>
<div><br>
</div>
<div>Cheers.<br>
</div>
<div>
<div>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">.___ ._ ..._ .. . ._.
.___ .. __ . _. . __.. ... .... ._ .__<br>
Entre dos pensamientos racionales <br>
hay infinitos pensamientos irracionales.<br>
<br>
</div>
</div>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, 24 Apr 2021 at 16:58,
Even Rouault <<a href="mailto:even.rouault@spatialys.com"
moz-do-not-send="true">even.rouault@spatialys.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote">Greg,<br>
<br>
There's a high chance for this to be completely PROJ behavior.
GDAL <br>
hardly knows about CRS those days :-)<br>
<br>
Could you share your input and output files ?<br>
<br>
Also set CPL_DEBUG=PROJ and PROJ_DEBUG=2 as environment
variables to see <br>
which transformations PROJ pickup : look for lines starting
with "PROJ: <br>
Using coordinate operation ..."<br>
<br>
With latest PROJ master (and also 6.3.2), I see that<br>
<br>
projinfo -s EPSG:6319 -t EPSG:7912 -o PROJ<br>
<br>
Candidate operations found: 1<br>
-------------------------------------<br>
Operation No. 1:<br>
<br>
unknown id, Conversion from NAD83(2011) (geog3D) to
NAD83(2011) <br>
(geocentric) + Inverse of ITRF2014 to NAD83(2011) (1) +
Conversion from <br>
ITRF2014 (geocentric) to ITRF2014 (geog3D), 0 m, Puerto Rico -
onshore <br>
and offshore. United States (USA) onshore and offshore -
Alabama; <br>
Alaska; Arizona; Arkansas; California; Colorado; Connecticut;
Delaware; <br>
Florida; Georgia; Idaho; Illinois; Indiana; Iowa; Kansas;
Kentucky; <br>
Louisiana; Maine; Maryland; Massachusetts; Michigan;
Minnesota; <br>
Mississippi; Missouri; Montana; Nebraska; Nevada; New
Hampshire; New <br>
Jersey; New Mexico; New York; North Carolina; North Dakota;
Ohio; <br>
Oklahoma; Oregon; Pennsylvania; Rhode Island; South Carolina;
South <br>
Dakota; Tennessee; Texas; Utah; Vermont; Virginia; Washington;
West <br>
Virginia; Wisconsin; Wyoming. US Virgin Islands - onshore and
offshore.<br>
<br>
PROJ string:<br>
+proj=pipeline<br>
+step +proj=axisswap +order=2,1<br>
+step +proj=unitconvert +xy_in=deg +z_in=m +xy_out=rad
+z_out=m<br>
+step +proj=cart +ellps=GRS80<br>
+step +inv +proj=helmert +x=1.0053 +y=-1.9092 +z=-0.5416
+rx=0.0267814<br>
+ry=-0.0004203 +rz=0.0109321 +s=0.00037 +dx=0.0008
+dy=-0.0006<br>
+dz=-0.0014 +drx=6.67e-05 +dry=-0.0007574
+drz=-5.13e-05 +ds=-7e-05<br>
+t_epoch=2010 +convention=coordinate_frame<br>
+step +inv +proj=cart +ellps=GRS80<br>
+step +proj=unitconvert +xy_in=rad +z_in=m +xy_out=deg
+z_out=m<br>
+step +proj=axisswap +order=2,1<br>
<br>
So it applies a time-dependent Helmert transformation, which
has also <br>
non-time dependent terms.<br>
<br>
However trying a bit, the transformation seems to introduce a
shift of <br>
about ~1 m or so, not 35 m<br>
<br>
$ echo 50 -100 0 | cs2cs -d 8 EPSG:6319 EPSG:7912<br>
50.00000754 -100.00001400 -0.68652183<br>
<br>
$ echo 50 -100 50.00000754 -100.00001400 | geod -I
+ellps=GRS80<br>
-50d7'11.377" 129d52'48.584" 1.308<br>
<br>
Even<br>
<br>
Le 24/04/2021 à 16:39, Greg Troxel a écrit :<br>
> Even Rouault <<a
href="mailto:even.rouault@spatialys.com" target="_blank"
moz-do-not-send="true">even.rouault@spatialys.com</a>>
writes:<br>
><br>
>> - <a
href="http://download.osgeo.org/gdal/3.3.0/gdal-3.3.0beta1.tar.gz"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://download.osgeo.org/gdal/3.3.0/gdal-3.3.0beta1.tar.gz</a><br>
> The tl;dr is:<br>
><br>
> - I'm seeing bad transforms NAD83/ITRF with 3.3.0beta1
but I do not<br>
> have any basis to blame 3.3.0 because a lot of other
things are in<br>
> flux.<br>
><br>
> - If you are using 3.3.0beta1 and transforms I suggest
looking at your<br>
> output data.<br>
><br>
><br>
><br>
> I have noticed a problem but I have little idea where it
is. I will be<br>
> looking into it myself but I wanted to mention it so that
others could<br>
> be on the lookout.<br>
><br>
> Besides updating to gdal, I'm doing a general software
freshening and<br>
> rebuilding lots of things, but aside from the gdal beta
my geo packages<br>
> haven't changed versions. I have proj 6.3.2 with
installed grids, which<br>
> was just rebuilt.<br>
><br>
> The background is that I'm mostly working in EPSG:6319
which is<br>
> NAD83(2011).<br>
><br>
> I transform to EPSG:7912 which is ITRF2014 to display the
data on<br>
> leaflet webmaps (as a proxy for WGS84 to avoid null
transforms).<br>
><br>
> I noticed that my points on the webmap were very far off,
displaced very<br>
> roughly 35m ESE. I then put an NAD83 version in the
webspace, and that<br>
> made things look ok (with the ~1 meter error from
treating NAD83 and<br>
> ITRF2014 as equal, surely).<br>
><br>
> I'm extracting things from a geopackage in 6319 like<br>
><br>
> ogr2ogr -f GeoJSON -t_srs "EPSG:7912" -s_srs
"EPSG:6319" FOO/issues.geojson foo.gpkg issues<br>
> ogr2ogr -f GeoJSON -t_srs "EPSG:6319" -s_srs
"EPSG:6319" FOO/issues-nad83.geojson foo.gpkg issues<br>
><br>
> which has previously been fine. I'm definitely getting
very large<br>
> offsets from two files extracted seconds apart from the
very same<br>
> geopackage.<br>
><br>
> So this is not a request for help, but if you are using
ogr2ogr to<br>
> transform datums, and you are using gdal 3.3.0beta1
especially with proj<br>
> 6, I'd suggest a quick look at your output data to see if
it seems ok.<br>
><br>
> I will be retesting after all the software rebuilds are
done, and<br>
> rolling back to released gdal. (Yes, I know proj 6.3 is
old and that I<br>
> should update.)<br>
><br>
> Thanks,<br>
> Greg<br>
<br>
-- <br>
<a href="http://www.spatialys.com" rel="noreferrer"
target="_blank" moz-do-not-send="true">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank"
moz-do-not-send="true">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>