[GRASSLIST:7811] Re: Synergy between Grass/Python/GMT revisited

[David Finlayson]

On 8/7/05, Dylan Beaudette <dylan at iici.no-ip.org> wrote:
> Greetings,
> 
> Sorry about the delay in getting back to everyone who has posted
> messages regarding this topic.
> 
> If everyone is still interested, I would like to chat some more about
> integrating GRASS and GMT via Python. I looked over David's r.out.gmt
> script (nice job!) and liked the approach much more than my bash
> scripts.

I am interested. My script is a hack that works for me, it should
really be refactored into a few UNIX-like commands that do each task
separately (and better). One for exporting the grass region and
metadata, one for exporting the colormap, etc.

> 
> Making hard copy maps is such an important part of any research project
> that deals with the spatial arrangement of object -- and yet there are
> not many ways of doing it efficiently with open source software. GMT
> provides a means to get the heavy lifting done, however the creation of
> complex maps  from multiple sources can be a bear. In addition, getting
> data from GRASS into GMT can be somewhat of a headache, especially
> vector data.
> 

Ultimately, GRASS's postscript/presentation facilities should be
enhanced. I can't help with that right now because I don't know
postscript (truthfully, I don't really know C that well either!). One
day I'll have the time to start hacking on that...

> I propose that in order to get this done, a group of interested
> individuals should spend some time working out a logical framework, and
> implementing it. Some previously raised questions should also be
> addressed:
> 
> 1. monolithic or modular?

Definitely modular. GRASS's real strength is it's Unix heritage. One
tool does one thing well, pipe the tools together. I've started
rewriting the portion of my script that converts colormaps as a filter
that reads in from stdin (or a file) and writes to stdout in
traditional UNIX-like fashion.

> 2. GRASS commands or via GDAL ?

> 3. how does QGIS fit in to this?

Personally, I worry about the role QGIS plays in GRASS development
(but that is another thread), I don't see how two commandline programs
like GRASS and GMT will include QGIS as a peer at this stage. Whatever
solution QGIS comes up with for wrapping a GUI around traditional
grass commands should work with the programs we develop though.

> 
> ...
> 
> personally i have mixed feelings about trying to cram this all into
> GDAL, rather the export of data i.e. :
> r.out.gmt
> v.out.gmt
> 
> might best be handled by GDAL , while GRASS specific things such as
> region, color palette, etc. :
> 
> g.out.colortable
> g.out.region
> g.out.gmt
> 

Exactly

> I can provide a place to post this discussion, and any progress via our
> lab's content management system.
> 

Lets talk about goals and time frames.

> Cheers,
> 
> 
> --
> Dylan Beaudette
> Soils and Biogeochemistry Graduate Group
> University of California at Davis
> 530.754.7341
> 
> 


-- 
David Finlayson
Marine Geology & Geophysics
School of Oceanography
Box 357940
University of Washington
Seattle, WA  98195-7940
USA

Office: Marine Sciences Building, Room 112
Phone: (206) 616-9407
Web: http://students.washington.edu/dfinlays