There are a few things that we should consider when creating the GRIDobj-class, at least I am currently facing a couple of challenges when implementing the new MATLAB version. I am not sure whether and, if, to what degree, some design decisions should apply to the Python-version as well. First of all, instead of storing the coordinate vectors, I used to use a refmat-Matrix, and computed the coordinate vectors, if needed from the row and column indices (subscripts) from the grid. MATLAB, however, has abandoned refmat and uses a worldfilematrix instead. The matrix is a 2x3 matrix that let's you calculate coordinates from the intrinsic coordinates (the subscripts) using matrix multiplication. Perhaps, we should use this approach in Python as well.
Moreover, I usually used a columns-start-north and a rows-start-west scheme. The latter is usual, the former may vary from tif to tif. To this end, I think it is not important and I am considering to remove it. Finally, it may be important that some rasters are stored with cell reference, and others with postings reference. This may mainly be important when exporting the data or calculating extents, but not affect any analysis tools.
I am currently redesigning the object slightly, and perhaps we should discuss these changes once we are back from EGU. Still, I think that these changes can subsequently applied also to the Python version and that this would likely not create any pain.
There are a few things that we should consider when creating the GRIDobj-class, at least I am currently facing a couple of challenges when implementing the new MATLAB version. I am not sure whether and, if, to what degree, some design decisions should apply to the Python-version as well. First of all, instead of storing the coordinate vectors, I used to use a refmat-Matrix, and computed the coordinate vectors, if needed from the row and column indices (subscripts) from the grid. MATLAB, however, has abandoned refmat and uses a worldfilematrix instead. The matrix is a 2x3 matrix that let's you calculate coordinates from the intrinsic coordinates (the subscripts) using matrix multiplication. Perhaps, we should use this approach in Python as well. Moreover, I usually used a columns-start-north and a rows-start-west scheme. The latter is usual, the former may vary from tif to tif. To this end, I think it is not important and I am considering to remove it. Finally, it may be important that some rasters are stored with cell reference, and others with postings reference. This may mainly be important when exporting the data or calculating extents, but not affect any analysis tools. I am currently redesigning the object slightly, and perhaps we should discuss these changes once we are back from EGU. Still, I think that these changes can subsequently applied also to the Python version and that this would likely not create any pain.