Are VCRS aware and VCRS naive comparisons allowed?

[erikmannerfelt]

I read through the interesting comments of #391 and got an idea/question about different VCRSs. As you mention, @rhugonnet, most or at least many people won't really think about this and will just assume it's correct from the start, which can lead to some weird corrections. cough Holmlund 2021 (strange that the ArcticDEMs had a 30 m bias, right??).

In both the builtin python datetime module (since 3.something) and Pandas, timezone aware datetime cannot be subtracted with timezone naive datetime. This makes for some frustration sometimes, but also makes sure that timezone issues more or less cannot happen, unless the explicitly provided (or implicitly read) tzinfo is wrong of course.

Would it make sense to have this feature for VCRSs as well? Perhaps it already is implemented and I just don't know it, but I wanted to bring it up formally.

[rhugonnet]

cough Holmlund 2021 (strange that the ArcticDEMs had a 30 m bias, right??).

:rofl:

Would it make sense to have this feature for VCRSs as well? Perhaps it already is implemented and I just don't know it, but I wanted to bring it up formally.

I agree we should have a similar type of behaviour for VCRSs! Right now we raise an error if there is none defined for the input DEM and the user wants to transform: https://github.com/GlacioHack/xdem/blob/main/xdem/dem.py#L250.

Were you thinking of this, or more specific sub-aspects of the VCRSs (like the epoch-dependent transformations mentioned by @dshean in his latest comments)?