[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