[GRASS-dev] Python Scripting

[Michael Barton]

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 at lists.osgeo.org>  
>> wrote:
>>> Date: Thu, 17 Jul 2008 11:23:58 -0400
>>> From: "Dan D'Alimonte" <dan at dalimonte.ca>
>>> Subject: Re: [GRASS-dev] Python Scripting
>>> To: grass-dev at lists.osgeo.org
>>> Message-ID: <487F640E.6030704 at 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 at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>