lon/lat vs projected coordinates
poplarShift opened this issue · comments
Hi, are there already plans to work in projected coordinates instead of lon/lat?
I see the nearest neighbour search uses some slow workaround (manual calculation of distance in km instead of a KDTree in projected coordinates), but the bathymetry interpolation works directly in lon/lat IIRC, which may be debatable.
Hi, I have been doing some tests with updating the structure of the grid of the grid object to being able to incorporate e.g. Cartesian grids. This would probably be the right time to think about including support for rotated coordinates as well?
The main idea I have is to separate this into a separate GridSkeleton class that only contains information about the grid points. This can then be of several types, but also return its own coordinates in e.g. UTM, WGS84 etc. It would probably be a good idea to also include the logic of finding nearest points in this skeleton class (which knows its own native coordinate system).
These different types of "skeletons" can then be used in all the other classes (Grid, Boundary, etc.), which can then concentrate on containing the data, and rely on the skeletons to calculate distances, doing coordinate transformations etc.
I don't have this in a branch yet, since I made some test code to see see that I don't run into problems with the implementation logic. I will probably open up a branch after Eastern, and you are very welcome to contribute to anything related to the different coordinate systems.
That sounds great!
Slightly related: I wonder if this would also be a good moment to do some refactoring in order to keep gridded data as much as possible in a gridded format? E.g. when reading bathymetry data, all the arrays get flattened. When the grids get big, this means we have to load in huge bathymetry arrays, instead of easily being able to load and interpolate data chunk-wise which is easier on memory.
Yes. Actually, we originally had the TopoReaders return gridded data. Then we came across sources where the data was not gridded, and we obviously don't want to grid the data in the reader, since that is done with the mesher. We therefore changes the format since we didn't want to have to keep checking which data we have.
I think you are right that this is highly related to the skeletons etc. and I think we can standardize the interface using them instead of forcing everything to xyz. Thanks for bringing this up!