<div dir="ltr"><div>Hi Steve,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 25, 2020 at 4:47 PM Steven Pawley <<a href="mailto:dr.stevenpawley@gmail.com">dr.stevenpawley@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div dir="auto" style="overflow-wrap: break-word;"><br><div>A couple of thoughts:</div><div><br></div><div><ul><li>An equivalent of a RasterRow class for 3D rasters to make it easier to read stacks of GRASS raster datasets into multidimensional arrays.</li></ul></div></div></div></blockquote><div><br></div><div>I agree, feature parity between 2D and 3D rasters is an important issue for GRASS GIS. RasterRow itself actually does not make that much sense for 3D rasters, although you could have the same interface. 3D raster library (API) works similarly to the segment library used in RasterSegment. You can look into some 3D raster modules to see it. I think with that, writing a 3D version of RasterRow/RasterSegment should be relatively straightforward.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div dir="auto" style="overflow-wrap: break-word;"><div><ul><li>Not really a Python addition as it mostly relates to the raster C library, but the ability to read windows/blocks/cubes of raster data, not just rows, IMHO would be a large improvement for raster data access into python.</li></ul></div></div></div></blockquote><div><br></div><div>With segment library in C and RasterSegment in Python, you have the additional computational cost of preparing it, but if you are repeating your readings or doing random access, it might be worth it, esp. now when it has all-in-memory mode and your rasters fit into memory. (The all-in-memory mode should work in Python at least in theory.)</div><div><br></div><div>The Python class does not allow that, but the C library can store arbitrary (plain numeric) data structure which includes the ability to store multiple rasters creating something like a cube. Of course, the same drawbacks as for one raster, but potentially greater benefits.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div dir="auto" style="overflow-wrap: break-word;"><div><ul><li> AFAIU, this is only currently possible by repeatedly moving the computational window, which I think was slower (when I tested this for reading chunks for r.learn.ml2) than the performance from windowed reading in other libraries (e.g. GDAL/Rasterio).</li></ul></div></div></div></blockquote><div>Sorry, I'm not sure what you mean here. Having other than a row-oriented internal representation and primary API  is something which is being brought up, but there are some caching techniques which might be better suited to resolve the task at hand (before diving into a complete library rewrite). Generally, if there is a significant performance issue somewhere, we should profile or otherwise identify the issue.<br></div><div><br></div><div>Best,<br></div><div>Vaclav<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div dir="auto" style="overflow-wrap: break-word;"><div><div><br></div><div>Steve</div><div><br><blockquote type="cite"><div>On Sep 24, 2020, at 8:29 PM, Vaclav Petras <<a href="mailto:wenzeslaus@gmail.com" target="_blank">wenzeslaus@gmail.com</a>> wrote:</div><br><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">Now would be a great time to do any large or small changes in the Python library. Let's discuss these. For example, there was a talk about more clear splitting of the ctypes dependent and independent code in grass.pygrass, about moving the library to a different place, there is the new grass.grassdb subpackage, PEP8/Black/Flake8, ... Is there anything *you* see as a priority for 8.0? Is there anything you can do before 8.0? Let's coordinate here.</div><br></div></blockquote></div><br></div></div></div></blockquote></div></div>