Re: Call for changes in the Python library

Hi Steve,

On Fri, Sep 25, 2020 at 4:47 PM Steven Pawley <[email protected]>
wrote:

>
> A couple of thoughts:
>
>
>    - An equivalent of a RasterRow class for 3D rasters to make it easier
>    to read stacks of GRASS raster datasets into multidimensional arrays.
>
>
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.


>    - 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.
>
>
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.)

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.


>
>    - 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).
>
> 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.

Best,
Vaclav


>
> Steve
>
> On Sep 24, 2020, at 8:29 PM, Vaclav Petras <[email protected]> wrote:
>
> 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.
>
>
>

_______________________________________________
grass-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/grass-dev