YAML area configuration does not allow to specify the dtype and dtype is ignored in equality comparisons

[gerritholl]

YAML area configuration does not allow to specify the dtype and dtype is ignored in equality comparisons

[djhoese]

I would consider dtype in the init method deprecated. At least it will not be included in future versions of the area definition class or at least not the ones I have planned.

[gerritholl]

How would you recommend user controlling the dtype when resampling? Keyword argument to resample?

[djhoese]

I'm tempted to say resampling should always use 64-bit floats for projected areas and optionally/possibly do 32-bit floats for lon/lats (degrees) coordinate systems.

[gerritholl]

I run out of memory with 64-bit floats, but my code completes fine when I force them to be 32 bits (projected area).

[djhoese]

Are the lon/lats being forced to 32-bit in your changes or the x/y coordinates? We've (Panu and me at least) discussed in the past on slack that 64-bit is required for x/y meter accuracy in most projections, but is way overkill for lon/lat degrees. At least that's my memory.

[djhoese]

Also, if this is running out of memory (OOM) with the "nearest" resampler then it is likely the generation of the KDTree that is the major contributor to the memory usage as the entire thing has to exist in memory at once (no dask chunking). The KDTree involves 3 axes (x, y, z) of geocentric coordinates...but I thought that was always 64-bit so I might be wrong about the dtype of the lon/lats contributing to this.