Dear all,
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.
Best,
Vaclav
Hi,
From my experience, the temporal framework is rather quirky, and might be in need of refactoring to fix some of those quirkiness (see for example https://github.com/OSGeo/grass/issues/629).
Most of it might be done without breaking the API, but the new major version could be an opportunity to break things for the better.
Cheers,
Laurent
Le jeu. 24 sept. 2020 à 21:29, Vaclav Petras <wenzeslaus@gmail.com> a écrit :
Dear all,
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.
Best,
Vaclav
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Hi Vaclav,
A couple of thoughts:
Steve
On Sep 24, 2020, at 8:29 PM, Vaclav Petras <wenzeslaus@gmail.com> 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.
Hi Laurent,
On Fri, Sep 25, 2020 at 2:53 PM Laurent C. <lrntct@gmail.com> wrote:
From my experience, the temporal framework is rather quirky, and might be in need of refactoring to fix some of those quirkiness (see for example https://github.com/OSGeo/grass/issues/629).
Most of it might be done without breaking the API, but the new major version could be an opportunity to break things for the better.
This sounds great. There are a lot of tests in place, so that’s a good starting point. I would be happy to discuss the details if you can work on the changes. Having a bigger flexibility with mapsets makes sense to me.
Best,
Vaclav
PS: Check a recent PR on GitHub for init/connect.
Cheers,
LaurentLe jeu. 24 sept. 2020 à 21:29, Vaclav Petras <wenzeslaus@gmail.com> a écrit :
Dear all,
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.
Best,
Vaclav
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Hi Steve,
On Fri, Sep 25, 2020 at 4:47 PM Steven Pawley <dr.stevenpawley@gmail.com> 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 <wenzeslaus@gmail.com> 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.