Re: [gdal-dev] Motion: adopt RFC 81: support for coordinate epochs in geospatial formats
Hi Sean, 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. 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. 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. 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... Now that I think about it, I think the RFC should say more about what it will do for the ensemble OGC:CRS84. 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. To me, it seems that the parameterization or description of coordinate epochs in OGC 19-005r4 is a bit sketchy. Could you precise ? Even, are you saying that coordinate shifts in PROJ are entirely functions of the datetime delta since the coordinate epoch? Currently what is available in PROJ for transformations between a dynamic CRS and a static CRS is mostly through using 15-parameter Helmert transformation: https://proj.org/operations/transformations/helmert.html (*). 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). To be complete on the topic, there are a few esoteric cases where https://proj.org/operations/transformations/deformation.html 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 And there's the very particular case of transformations between ITRF96 and NZGD2000 (New Zealand) which uses a more complex deformation model (https://proj.org/operations/transformations/defmodel.html), 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. Even -- http://www.spatialys.com My software is free, but my time generally not. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: adopt RFC 81: support for coordinate epochs in geospatial formats
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 > 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
Re: [gdal-dev] Motion: adopt RFC 81: support for coordinate epochs in geospatial formats
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 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] leav
___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
