I've tried pinging David Sandwell at Scripps, geodesy / rtk / surveying folks at UNH CCOM, and Paul Wessel / Dietmar Muller of GMT about a week ago and haven't gotten any useful response.
I'm +0 and feeling like Sean that we really could use some feedback from other communities. Having epoch info is great, but I feel like I have no clue about what is a sufficient solution. -kurt On Mon, May 24, 2021 at 3:40 PM Sean Gillies via gdal-dev < gdal-dev@lists.osgeo.org> wrote: > Hi Even, Howard: > > 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. > > On Thu, May 13, 2021 at 10:01 AM Even Rouault <even.roua...@spatialys.com> > wrote: > >> Howard, >> > It is magical >> > ------------------- >> > >> > 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. >> Having different results in coordinate transformations due to have will >> not be much different than using different PROJ versions using different >> versions of the EPSG database, possibly with different set of grids >> installed. >> > > Howard, are you suggesting that there should be a configuration option to > opt in to this new feature? > > 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. > > >> > >> > It extends existing formats in GDAL's own way >> > --------------------------------------------------------------- >> > >> > 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. >> We are not going to invent a new raster or vector format just to add a >> coordinate epoch into it, right ? So this proposal does minor and >> backward compatible enhancements to popular existing formats. >> > >> > > 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. > > Now that I think about it, I think the RFC should say more about what it > will do for the ensemble OGC:CRS84. > > >> > No corresponding socializing activity >> > ------------------------------------------------- >> > >> > 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. >> Well, this is a public RFC for everybody awareness, and there will be a >> page on GDAL doc. And I've created tickets on the GeoTIFF and GeoPackage >> OGC github repos pointing to it. I don't necessarily expect much follow >> up from them though, but at least we'll have tried to make advance the >> topic a bit. >> > >> > Is the format of epoch standardized? >> > ------------------------------------------------- >> > >> > 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? >> >> This format is a floating point number and is the accepted way of >> encoding coordinate epochs. The after decimal point part represents the >> fraction of the year. It is referenced in "OGC Abstract Specification >> Topic 2: Referencing by coordinates" >> (https://docs.opengeospatial.org/as/18-005r4/18-005r4.html). In table 4: >> coordinateEpoch: "date at which coordinates are referenced to a dynamic >> coordinate reference system, expressed as a decimal year in the >> Gregorian calendar. Example: 2017-03-25 in the Gregorian calendar is >> epoch 2017.23." >> >> (31+28+25) / 365. = 0.23... >> >> Two digits after the decimal point should be enough in practice. For >> 'slow' and continuous phenomenons like plate drift motion, an error of a >> couple days will not change the result by more than a fraction of >> millimetre. If you use a deformation model that takes into account >> earthquakes however, you could perhaps need to add a 3rd digit to >> identify precisely the day. >> >> Even >> > > To me, it seems that the parameterization or description of coordinate > epochs in OGC 19-005r4 is a bit sketchy. > > Even, are you saying that coordinate shifts in PROJ are entirely functions > of the datetime delta since the coordinate epoch? > > -- > Sean Gillies > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev