[gdal-dev] Motion: adopt RFC 81: support for coordinate epochs in geospatial formats
Even Rouault
even.rouault at spatialys.com
Tue May 25 06:57:54 PDT 2021
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.
--
http://www.spatialys.com
My software is free, but my time generally not.
More information about the gdal-dev
mailing list