<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><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 13, 2021 at 10:01 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Howard,<br>
> It is magical<br>
> -------------------<br>
><br>
> If you have GDAL-extended versions of a few select data formats and you have the correct chain of PROJ and GDAL, the behavior of your coordinates is going to change for various transformations. This could be confusing and challenging to track down in debugging scenarios. The discrepancies between doing the same transformations in different softwares will be especially noticeable.<br>
Having different results in coordinate transformations due to have will <br>
not be much different than using different PROJ versions using different <br>
versions of the EPSG database, possibly with different set of grids <br>
installed.<br></blockquote><div><br></div><div>Howard, are you suggesting that there should be a configuration option to opt in to this new feature?</div><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 class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
><br>
> It extends existing formats in GDAL's own way<br>
> ---------------------------------------------------------------<br>
><br>
> Are there many other cases where GDAL augments and extends behavior of formats by bolting on metadata bits? I can think of some GeoTIFF tags where GDAL has done this in the past. Some of them have been adopted industry-wide, but most have not. We definitely haven't done that to a long list of formats like this RFC proposes to do.<br>
We are not going to invent a new raster or vector format just to add a <br>
coordinate epoch into it, right ? So this proposal does minor and <br>
backward compatible enhancements to popular existing formats.<br>
><br></blockquote><div><br></div><div>For GeoJSON, at least, I think proposing a "coordinate_epoch" property is pragmatic. This doesn't do anything for GeoJSON feature sequences, though. And it doesn't do anything about data that's already out there that will never be re-processed.</div><div><br></div><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 class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> No corresponding socializing activity<br>
> -------------------------------------------------<br>
><br>
> Is GDAL going to go to the GeoJSON, GeoPackage, GeoTIFF, Flatgeobuf, GML, JPEG2000, KML, and Shapefile communities and advocate for these improvements? It would be a lot of time and effort to go back after the fact and officially augment all of these formats with epoch metadata.  Many of these are never going to have new versions either, so there isn't much hope of a new format version coming along with support for coordinate epochs.<br>
Well, this is a public RFC for everybody awareness, and there will be a <br>
page on GDAL doc. And I've created tickets on the GeoTIFF and GeoPackage <br>
OGC github repos pointing to it. I don't necessarily expect much follow <br>
up from them though, but at least we'll have tried to make advance the <br>
topic a bit.<br>
><br>
> Is the format of epoch standardized?<br>
> -------------------------------------------------<br>
><br>
> The proposed epoch format, such as 2021.3, *looks* like a floating point number, but it isn't really, is it? Do you ever need more precision than a year and a day? *shrug* It seems like it's own special time format. Is there a standard time format that could instead be used here?<br>
<br>
This format is a floating point number and is the accepted way of <br>
encoding coordinate epochs. The after decimal point part represents the <br>
fraction of the year. It is referenced in "OGC Abstract Specification <br>
Topic 2: Referencing by coordinates" <br>
(<a href="https://docs.opengeospatial.org/as/18-005r4/18-005r4.html" rel="noreferrer" target="_blank">https://docs.opengeospatial.org/as/18-005r4/18-005r4.html</a>). In table 4: <br>
coordinateEpoch: "date at which coordinates are referenced to a dynamic <br>
coordinate reference system, expressed as a decimal year in the <br>
Gregorian calendar. Example: 2017-03-25 in the Gregorian calendar is <br>
epoch 2017.23."<br>
<br>
(31+28+25) / 365. = 0.23...<br>
<br>
Two digits after the decimal point should be enough in practice. For <br>
'slow' and continuous phenomenons like plate drift motion, an error of a <br>
couple days will not change the result by more than a fraction of <br>
millimetre. If you use a deformation model that takes into account <br>
earthquakes however, you could perhaps need to add a 3rd digit to <br>
identify precisely the day.<br>
<br>
Even<br></blockquote><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><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><br></div></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Sean Gillies</div></div></div>