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