[GRASSLIST:7810] Synergy between Grass/Python/GMT revisited

GRASS GRASS user
, ,
1

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.

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.

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?
2. GRASS commands or via GDAL ?
3. how does QGIS fit in to this?

...

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

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

Cheers,

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

2

On 8/7/05, Dylan Beaudette <dylan@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

3

David Finlayson wrote:

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!).

I'm reasonably familiar with PostScript.

> 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...

It would take a long time to catch up to GMT, and I'm not sure there's
much point in duplicating all that effort. It seems (to me) to make
more sense to leverage what GMT already provides by making it easier
to export data from GRASS into GMT. The reverse isn't nearly as
useful.

Although some of the more fundamental features should be implemented
directly. E.g. r.out.ps, v.out.ps.

The main issue is that the flexibility of PostScript means that there
are an unlimited number of options which you could reasonably
implement, e.g. line and fill styles, text formatting etc. We need to
avoid trying to implement too much.

> 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.

Agreed.

Personally, I'd prefer PostScript versions of the main d.* commands
rather than something like ps.map.

The hardest part is designing the framework. Actually implementing a
program which reads a raster and emits PostScript is simple enough.

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

The actualy discussion should ideally occur on the development list
(grass5@grass.itc.it) and/or here.

--
Glynn Clements <glynn@gclements.plus.com>