[GRASS-dev] Python Scripting

[Dan D'Alimonte]

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