<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Hi Sean,<br>
<blockquote type="cite"
cite="mid:CADPhZXzPk+HAssvs0VMHFZWFy05KJx28AGfj6kCiSj=FUe_JNA@mail.gmail.com">
<div dir="ltr">
<div>Hi Even, Howard:</div>
<div><br>
</div>
<div>I'm inclined to approve, but I feel like there should be
more discussion, not just among PROJ developers and developers
of cutting edge formats. We should work to draw a wider group
in on this.</div>
</div>
</blockquote>
Various OGC standard working groups are aware of that topic since
this was raised I think in a plenary meeting more than one year ago.
I see that in Testbed 17 the working group on the "OGC Features and
Geometry JSON" (the "extension" of GeoJSON) is aware of that, but
has not proposed any solution. I've just pointed them to my
proposal.<br>
<blockquote type="cite"
cite="mid:CADPhZXzPk+HAssvs0VMHFZWFy05KJx28AGfj6kCiSj=FUe_JNA@mail.gmail.com">
<div dir="ltr"><br>
<div class="gmail_quote">Howard, are you suggesting that there
should be a configuration option to opt in to this new
feature?
<div><br>
</div>
<div>A surprise 1-2 meter shift is going to break builds and
applications, I agree. I think a lot of us are tolerating
inaccuracy due to using time-varying CRS but are going to be
caught out by changes in the actual numbers.</div>
</div>
</div>
</blockquote>
The mere introduction of this new capability isn't going to change
any behavior. It is only going to change behavior if people do add a
coordinate epoch in their datasets, and in that case, one can expect
them to want more accurate coordinate transformations. That said
adding a config option in the OGRProjCT class to ignore the
coordinate epoch is trivial...<br>
<blockquote type="cite"
cite="mid:CADPhZXzPk+HAssvs0VMHFZWFy05KJx28AGfj6kCiSj=FUe_JNA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote"><br>
<div>Now that I think about it, I think the RFC should say
more about what it will do for the ensemble OGC:CRS84.</div>
</div>
</div>
</blockquote>
I'm not sure what kind of transformations will be possible when
operating on the WGS 84 ensemble. Within what is available strictly
speaking in EPSG, probably none. But we have had repeated
discussions on the PROJ mailing list regarding this, and potentially
one option could be to consider that a "recent" coordinate epoch on
WGS 84 would mean that people actually use the latest WGS 84
realization, WGS 84 (G1762) currently, and so use transformations
available from/to that realization. But nothing regarding this has
been implemented yet. To get a time-dependent transformation, you
need to specify a non-ensemble datum.<br>
<blockquote type="cite"
cite="mid:CADPhZXzPk+HAssvs0VMHFZWFy05KJx28AGfj6kCiSj=FUe_JNA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<div><br>
</div>
<div>To me, it seems that the parameterization or description
of coordinate epochs in OGC 19-005r4 is a bit sketchy.</div>
</div>
</div>
</blockquote>
Could you precise ?<br>
<blockquote type="cite"
cite="mid:CADPhZXzPk+HAssvs0VMHFZWFy05KJx28AGfj6kCiSj=FUe_JNA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>Even, are you saying that coordinate shifts in PROJ are
entirely functions of the datetime delta since the
coordinate epoch?</div>
</div>
</div>
</blockquote>
<p>Currently what is available in PROJ for transformations between a
dynamic CRS and a static CRS is mostly through using 15-parameter
Helmert transformation:
<a class="moz-txt-link-freetext" href="https://proj.org/operations/transformations/helmert.html">https://proj.org/operations/transformations/helmert.html</a> (*).
Those Helmert transformations can have non-time dependent
components (the "classic" 7-parameter transformtion, ala TOWGS84)
+ a time-dependant component that is generally a rotation in
spherical coordinates w.r.t Earth centre and of an amplitude
proportional to (coordinate_epoch - central_epoch) where
central_epoch is a constant of the transformation (e.g the GDA2020
to ITRF2014 transformation uses central_epoch=2020.0). But they
are not "entirely functions of the datetime delta", since the
value of the longitude, latitude, ellipsoidal height of the
coordinate has also an influence on the result (not completely
sure to understand your question).</p>
<p>To be complete on the topic, there are a few esoteric cases where
<a class="moz-txt-link-freetext" href="https://proj.org/operations/transformations/deformation.html">https://proj.org/operations/transformations/deformation.html</a> grids
are used, and the amplitude of the correction is also proportional
to (coordinate_epoch - central_epoch), but this is specific to a
NKG (Nordic countries) CRS code <br>
</p>
<p>And there's the very particular case of transformations between
ITRF96 and NZGD2000 (New Zealand) which uses a more complex
deformation model
(<a class="moz-txt-link-freetext" href="https://proj.org/operations/transformations/defmodel.html">https://proj.org/operations/transformations/defmodel.html</a>), where
the time parameter can decide if corrections related to
earthquakes are applied depending on the location and if you're
before or after the date of the earthquake.<br>
</p>
<p>Even</p>
--
<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>