On Tue, 25 May 2021 at 23:58, Even Rouault <even.roua...@spatialys.com> wrote: > > > Le 25/05/2021 à 15:30, Howard Butler a écrit : > > > >> On May 24, 2021, at 5:39 PM, Sean Gillies <s...@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.roua...@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@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
