[gdal-dev] Motion: adopt RFC 81: support for coordinate epochs in geospatial formats

[Nyall Dawson]

On Tue, 25 May 2021 at 23:58, Even Rouault <even.rouault at spatialys.com> wrote:
>
>
> Le 25/05/2021 à 15:30, Howard Butler a écrit :
> >
> >> On May 24, 2021, at 5:39 PM, Sean Gillies <sean at mapbox.com> wrote:
> >>
> >> Howard, are you suggesting that there should be a configuration option to opt in to this new feature?
> > Yes, I think it should be explicitly opt-in, not silently opt-out for the time being.
> >
> >
> >> On May 24, 2021, at 6:15 PM, Even Rouault <even.rouault at spatialys.com> wrote:
> >>
> >> 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...
> >>
> >
> > I'm glad you are getting traction with the various format groups on the topic, but that process is going to take a very long time to matriculate, and in many cases official blessing won't ever be pronounced. Let's make the behavior for applying the transformations *and* writing the metadata an explicit opt-in.
>
> Do you mean you would also want a per-driver option,
> WRITE_COORDINATE_EPOCH=YES, in addition to having attached a coordinate
> epoch to the CRS ? It seems to me that we are making the life of users
> harder, whereas we should make it easier to get it right. If people have
> already taken the step of attaching the coordinate epoch to the CRS, we
> can assume they want it to be preserved as much as possible. When people
> write a GeoTIFF with a CRS with a TOWGS84 override, we write the
> GeogTOWGS84GeoKey extension key without asking them.
>
> Is your worry about non-GDAL implementations ? At worse, they will
> ignore the coordinate epoch. You can't currently expect software
> implementations with different coordinate transformation engines to give
> the same result for the "simple" standard static CRS to static CRS
> situation.

Can I make the suggestion that a subset of
https://github.com/OSGeo/gdal/pull/3827 could be created and be merged
on its own? Specifically the commits which add the underlying API for
GDAL to handle epochs should be controversy-free and suitable for
merge outside of the larger/trickier question of patching in support
to the data formats.

Nyall


>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev