[Gdal-dev] Re: [GRASSLIST:864] GMT / GRASS use / shp2gmt
Dylan Beaudette
dylan.beaudette at gmail.com
Tue Apr 25 17:14:00 EDT 2006
Hi Trevor:
(sorry for any cross-posts, hoping to get some extra traction on this topic)
On Tuesday 25 April 2006 01:13 pm, Trevor Wiens wrote:
> Grudgingly I'm using GMT after working through Dylan's example and am
> getting it to be somewhat functional.
:) sorry for any slightly outdated material on that site
(http://169.237.35.250/~dylan/grass_user_group/map1.html). I have a lot of
changes that I would like to make, along with some more examples...
Unfortunately I don't have a lot of spare time these days.
Another, simpler example using something other than UTM projected data can be
found here:
http://casoilresource.lawr.ucdavis.edu/drupal/node/102
Another (unfinished) collection of samples can be found here:
http://casoilresource.lawr.ucdavis.edu/drupal/node/51
> I will be needing to script the building of a large number of maps
> which I may store either in PostGIS or GRASS.
you might find the scripts "g.fieldsheet.sh" and "make_fieldsheets.sh" found
on the third URL above useful templates. I used these along with some
additional bash scripts to automate the process of making about 2 hundred
maps for soil survey operations. examples here:
http://169.237.35.250/~dylan/NPS/#fieldsheets
ask if you would like some of the details.
> I've noticed in the use of shp2gmt that there is no way of adding in a
> z attribute for use with the thematic colour assignment feature in GMT.
> If necessary I can extract bits based on different attributes and add
> them in separately, but it would be nice to be able to simply define a
> colour them once and be done with it. Any suggestions on how I can turn
> an attribute column in GRASS into a z-element that will be converted
> with shp2gmt would be appreciated.
>
> T
Yes. This is a major drawback for multi-class maps. Unfortunately I did not
have the time, nor expertise to customize shp2gmt for inclusion of symbology
parameters. There has been some discussion on the GMT and GDAL lists about
the possible creation of a OGR GMT driver ... but I haven't heard any news on
this topic for a while. I have been toying with the idea of a new GRASS
command called 'v.out.gmt' which would export simple geometry along with
selected symbology to the GMT format.
A starting point would be to use `v.out.ascii format=standard` along with
v.out.ascii.db to add an attribute on the starting line of each feature.
the resulting file for lines or closed polygons would look like this:
> -W2/255/1/1 -G255/0/0
660835 4040837
660827 4040845
660819 4040846
> -W2/255/1/255
660835 4040837
660827 4040845
660819 4040846
the '-W' and '-G' control pen and fill colors.
for points of varying symbol size, the third field is the symbol size:
> -G255/0/0 -W2/0/255/0
660835 4040837 1
> -G0/255/255 -W2/0/255/0
660827 4040845 9
An alternate method is to use an external CPT file for colors:
psxy [...] -L -Cthe_cpt_file.cpt > output.ps
each polygon stanza should have the following:
> -Z<value>
661096.53862171 4041121.73826666
661093.98591761 4041116.63285845
661091.4332135 4041111.52745023
661083.77510118 4041108.97474613
660835.31190146 4040837.53720944
where <value> is a number referenced to a color in the CPT file
...So where to start? I think that it shouldn't be too hard to implement
simple vector->GMT conversion, based on the code found in v.out.ascii , and
as Hamish suggested a while ago ps.map (for attribute access).
A skeleton GRASS module could look something like:
src/vector/v.out.gmt/
---main.c----
1. get user args and init pointers
2. detect feature type
3. loop through features:
1. extract & write symbology
2. write vertex records
3. optionally close polygon
4. add to buffer, next feature
4. flush buffer to disk
5. clean-up and exit
------------
Apologies for the long post. Ideally it would be great to have GMT vector
support in GDAL/OGR. Raster support is nearly ready through r.out.bin |
xyz2grd -or- r.out.gdal format=NetCDF ...
Cheers,
--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341
More information about the Gdal-dev
mailing list