[GRASS-dev] Python Scripting

GRASS GRASS developer
1

Hi Dan,

This sounds intriguing. What we need to ask is what would this gain us and how much work would it take.

Michael

On Jul 17, 2008, at 9:00 AM, <grass-dev-request@lists.osgeo.org> wrote:

Date: Thu, 17 Jul 2008 11:23:58 -0400
From: "Dan D'Alimonte" <dan@dalimonte.ca>
Subject: Re: [GRASS-dev] Python Scripting
To: grass-dev@lists.osgeo.org
Message-ID: <487F640E.6030704@dalimonte.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I'm curious if any though has been given to developing an actual GRASS
library for Python that goes beyond calling executables with system calls?

I'm thinking about a model that encapsulates the GRASS environment and
allows for both low-level processing like the C library, and high-level
use of existing modules like shell scripts.

I'll admit I have not given this a lot of though, but a hypothetical,
and quickly thought-out, example could be something like:

from grass import module, layer, cell, parser

def r_add(inLayers, outLayer):
  for outCell in outLayer.cells:
    sum = cell(type=outLayer.cellType)
    for l in inLayers:
      c = l.getCellAtSameLocation(outCell)
      if c.value==cell.null:
        sum.value = cell.null
        break
      sum.value += c.value
    outCell.value = c.value
  outLayer.commit()
    
if __name__ == "__main__":
  # Set up module information here
  # Set up and run parser
  # Open input layers
  # Create new layer for output
  # call r_add()
  # close layers

I don't know if this would even be feasible, but I think it would make a
nice addition to GRASS's Python support. If done right it would even
allow other python-based GRASS modules to be called-on without having to
make a system-call (eg. from raster_add import r_add).

As to existing modules, what about a helper function to access then?

module.executeModule( name="r.stats", options={ "input":
"elevation.dem,slope,aspect", "fs": ",", "output": "elev.csv"},
flags=["q", "1", "n", "g"] )

It was just a thought, and would require a lot more thought and work to
design properly. I, frankly, do not have enough understanding of GRASS
internals to even know where to begin.

2

That's why I put it to the mailing list. I was picturing something that acted as an intermediate between the low-level, direct data access nature of the C library and the high-level nature of shell scripts, This could possibly easily allow access to both in the same program. In situations where shell scripts' limits make you jump through hoops and the C library is just too low-level, a solid Python library would be of use in developing GRASS programs. It could also allow for more people access to GRASS and GIS programming by providing a language with a much lower learning curve then C.

As to whether it is needed or worth undertaking, that would be up to the community. What I put below was based on some periodic thoughts I've had in the past, but an actual design and implementation would need to be developed if there is enough interest. And if Python is indeed the right environment to do this in (I know speed of raster processing has already been brought up).

-- Dan.

Michael Barton wrote:

Hi Dan,

This sounds intriguing. What we need to ask is what would this gain us and how much work would it take.

Michael

On Jul 17, 2008, at 9:00 AM, <grass-dev-request@lists.osgeo.org> wrote:

Date: Thu, 17 Jul 2008 11:23:58 -0400
From: "Dan D'Alimonte" <dan@dalimonte.ca>
Subject: Re: [GRASS-dev] Python Scripting
To: grass-dev@lists.osgeo.org
Message-ID: <487F640E.6030704@dalimonte.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I'm curious if any though has been given to developing an actual GRASS
library for Python that goes beyond calling executables with system calls?

I'm thinking about a model that encapsulates the GRASS environment and
allows for both low-level processing like the C library, and high-level
use of existing modules like shell scripts.

I'll admit I have not given this a lot of though, but a hypothetical,
and quickly thought-out, example could be something like:

from grass import module, layer, cell, parser

def r_add(inLayers, outLayer):
    for outCell in outLayer.cells:
        sum = cell(type=outLayer.cellType)
        for l in inLayers:
            c = l.getCellAtSameLocation(outCell)
            if c.value==cell.null:
                sum.value = cell.null
                break
            sum.value += c.value
        outCell.value = c.value
    outLayer.commit()
       if __name__ == "__main__":
    # Set up module information here
    # Set up and run parser
    # Open input layers
    # Create new layer for output
    # call r_add()
    # close layers

I don't know if this would even be feasible, but I think it would make a
nice addition to GRASS's Python support. If done right it would even
allow other python-based GRASS modules to be called-on without having to
make a system-call (eg. from raster_add import r_add).

As to existing modules, what about a helper function to access then?

module.executeModule( name="r.stats", options={ "input":
"elevation.dem,slope,aspect", "fs": ",", "output": "elev.csv"},
flags=["q", "1", "n", "g"] )

It was just a thought, and would require a lot more thought and work to
design properly. I, frankly, do not have enough understanding of GRASS
internals to even know where to begin.

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

3

I can see how it could be handy to be able to access GRASS library functions from Python. Would this differ from the Python SWIG interface? I thought that SWIG was supposed to allow this?

Or maybe I misunderstand. Sorry if I am missing something.

Michael

On Jul 18, 2008, at 3:29 PM, Dan D'Alimonte wrote:

That's why I put it to the mailing list. I was picturing something that acted as an intermediate between the low-level, direct data access nature of the C library and the high-level nature of shell scripts, This could possibly easily allow access to both in the same program. In situations where shell scripts' limits make you jump through hoops and the C library is just too low-level, a solid Python library would be of use in developing GRASS programs. It could also allow for more people access to GRASS and GIS programming by providing a language with a much lower learning curve then C.

As to whether it is needed or worth undertaking, that would be up to the community. What I put below was based on some periodic thoughts I've had in the past, but an actual design and implementation would need to be developed if there is enough interest. And if Python is indeed the right environment to do this in (I know speed of raster processing has already been brought up).

-- Dan.

Michael Barton wrote:

Hi Dan,
This sounds intriguing. What we need to ask is what would this gain us and how much work would it take.
Michael
On Jul 17, 2008, at 9:00 AM, <grass-dev-request@lists.osgeo.org> wrote:

Date: Thu, 17 Jul 2008 11:23:58 -0400
From: "Dan D'Alimonte" <dan@dalimonte.ca>
Subject: Re: [GRASS-dev] Python Scripting
To: grass-dev@lists.osgeo.org
Message-ID: <487F640E.6030704@dalimonte.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I'm curious if any though has been given to developing an actual GRASS
library for Python that goes beyond calling executables with system calls?

I'm thinking about a model that encapsulates the GRASS environment and
allows for both low-level processing like the C library, and high-level
use of existing modules like shell scripts.

I'll admit I have not given this a lot of though, but a hypothetical,
and quickly thought-out, example could be something like:

from grass import module, layer, cell, parser

def r_add(inLayers, outLayer):
   for outCell in outLayer.cells:
       sum = cell(type=outLayer.cellType)
       for l in inLayers:
           c = l.getCellAtSameLocation(outCell)
           if c.value==cell.null:
               sum.value = cell.null
               break
           sum.value += c.value
       outCell.value = c.value
   outLayer.commit()
      if __name__ == "__main__":
   # Set up module information here
   # Set up and run parser
   # Open input layers
   # Create new layer for output
   # call r_add()
   # close layers

I don't know if this would even be feasible, but I think it would make a
nice addition to GRASS's Python support. If done right it would even
allow other python-based GRASS modules to be called-on without having to
make a system-call (eg. from raster_add import r_add).

As to existing modules, what about a helper function to access then?

module.executeModule( name="r.stats", options={ "input":
"elevation.dem,slope,aspect", "fs": ",", "output": "elev.csv"},
flags=["q", "1", "n", "g"] )

It was just a thought, and would require a lot more thought and work to
design properly. I, frankly, do not have enough understanding of GRASS
internals to even know where to begin.

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
grass-dev Info Page

4

Having never used SWIG, my understanding was it gives you access to the functions in the C library? This is a good thing, yes, but I was thinking of something beyond this. As I stated earlier, to allow programming for GRASS at a higher level the the C functions, including making use of Python's Object Oriented features to encapsulate GRASS data structures and processes. For example, a RasterLayer class that contains raster data, with it associated spatial characteristics, that can provide interators over rows of cells, columns of cells, individual cells, or moving windows such as a 3x3 matrix.

And apologies in return if I've been unclear.

Michael Barton wrote:

I can see how it could be handy to be able to access GRASS library functions from Python. Would this differ from the Python SWIG interface? I thought that SWIG was supposed to allow this?

Or maybe I misunderstand. Sorry if I am missing something.

Michael

On Jul 18, 2008, at 3:29 PM, Dan D'Alimonte wrote:

That's why I put it to the mailing list. I was picturing something that acted as an intermediate between the low-level, direct data access nature of the C library and the high-level nature of shell scripts, This could possibly easily allow access to both in the same program. In situations where shell scripts' limits make you jump through hoops and the C library is just too low-level, a solid Python library would be of use in developing GRASS programs. It could also allow for more people access to GRASS and GIS programming by providing a language with a much lower learning curve then C.

As to whether it is needed or worth undertaking, that would be up to the community. What I put below was based on some periodic thoughts I've had in the past, but an actual design and implementation would need to be developed if there is enough interest. And if Python is indeed the right environment to do this in (I know speed of raster processing has already been brought up).

-- Dan.

5

On Jul 21, 2008, at 7:52 AM, Dan D'Alimonte wrote:

Having never used SWIG, my understanding was it gives you access to the functions in the C library? This is a good thing, yes, but I was thinking of something beyond this. As I stated earlier, to allow programming for GRASS at a higher level the the C functions, including making use of Python's Object Oriented features to encapsulate GRASS data structures and processes. For example, a RasterLayer class that contains raster data, with it associated spatial characteristics, that can provide interators over rows of cells, columns of cells, individual cells, or moving windows such as a 3x3 matrix.

My understanding is that the Python GRASS SWIG interface makes this possible. However, wrapping this into a nice Python library would make it more accessible to a broader audience.

And apologies in return if I've been unclear.

Probably my lack of understanding of the more advanced aspects of Python.

Michael

Michael Barton wrote:

I can see how it could be handy to be able to access GRASS library functions from Python. Would this differ from the Python SWIG interface? I thought that SWIG was supposed to allow this?
Or maybe I misunderstand. Sorry if I am missing something.
Michael
On Jul 18, 2008, at 3:29 PM, Dan D'Alimonte wrote:

That's why I put it to the mailing list. I was picturing something that acted as an intermediate between the low-level, direct data access nature of the C library and the high-level nature of shell scripts, This could possibly easily allow access to both in the same program. In situations where shell scripts' limits make you jump through hoops and the C library is just too low-level, a solid Python library would be of use in developing GRASS programs. It could also allow for more people access to GRASS and GIS programming by providing a language with a much lower learning curve then C.

As to whether it is needed or worth undertaking, that would be up to the community. What I put below was based on some periodic thoughts I've had in the past, but an actual design and implementation would need to be developed if there is enough interest. And if Python is indeed the right environment to do this in (I know speed of raster processing has already been brought up).

-- Dan.

6

On Mon, Jul 21, 2008 at 7:17 PM, Michael Barton <michael.barton@asu.edu> wrote:

On Jul 21, 2008, at 7:52 AM, Dan D'Alimonte wrote:

Having never used SWIG, my understanding was it gives you access to the
functions in the C library? This is a good thing, yes, but I was thinking of
something beyond this. As I stated earlier, to allow programming for GRASS
at a higher level the the C functions, including making use of Python's
Object Oriented features to encapsulate GRASS data structures and processes.
For example, a RasterLayer class that contains raster data, with it
associated spatial characteristics, that can provide interators over rows of
cells, columns of cells, individual cells, or moving windows such as a 3x3
matrix.

My understanding is that the Python GRASS SWIG interface makes this
possible. However, wrapping this into a nice Python library would make it
more accessible to a broader audience.

I would like to remember this proposal:
http://wiki.osgeo.org/wiki/OSGeo_Python_Library

Markus