Hi,
ps.map now has an optional 'border' instruction to control the
existence, color, and width of the box around the map area.
this resolves wish #3389.
enjoy,
Hamish
On Wed, 7 Feb 2007, Hamish wrote:
Hi,
ps.map now has an optional 'border' instruction to control the
existence, color, and width of the box around the map area.this resolves wish #3389.
That's great! Will be a godsend to someone somewhere I'm sure.
Paul
Hamish:
> ps.map now has an optional 'border' instruction to control the
> existence, color, and width of the box around the map area.
Paul:
That's great! Will be a godsend to someone somewhere I'm sure.
The next step is to write a wxPython GUI cartographic composer frontend
which will create a ps.map instructions file and run that to create a
PostScript file. ps.map can make very professional hardcopy maps, but it
needs a user friendly front-end.
see
http://grass.gdf-hannover.de/wiki/GRASS_GUI#Components
There was a TclTk start for this in d.m, gui/tcltk/d.m/print.tcl.
This is not meant replace a Print button for the current display
monitor, it's a stand alone hardcopy plot generator. That print button
could write to a ps.map file, but maybe it is very easy to write
directly to PostScript from the map canvas, like Michael has done for
gis.m?
Hamish
hi,
2007/2/8, Hamish <hamish_nospam@yahoo.com>:
Hamish:
> > ps.map now has an optional 'border' instruction to control the
> > existence, color, and width of the box around the map area.Paul:
> That's great! Will be a godsend to someone somewhere I'm sure.The next step is to write a wxPython GUI cartographic composer frontend
which will create a ps.map instructions file and run that to create a
PostScript file. ps.map can make very professional hardcopy maps, but it
needs a user friendly front-end.see
http://grass.gdf-hannover.de/wiki/GRASS_GUI#ComponentsThere was a TclTk start for this in d.m, gui/tcltk/d.m/print.tcl.
This is not meant replace a Print button for the current display
monitor, it's a stand alone hardcopy plot generator. That print button
could write to a ps.map file, but maybe it is very easy to write
directly to PostScript from the map canvas, like Michael has done for
gis.m?Hamish
As soon as new map display class will be defined in wxPython, I would
like to build georectifing, ps.map and digitizing tool on top of it.
Michael is currently working on it. We are using wxPython 2.8, and
there are small problems with this version on debian-based distros
(compilation works well, but the packaging system does not like some
definitions).
Jachym
--
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
On 08/02/07 10:11, Jáchym Čepický wrote:
hi,
2007/2/8, Hamish <hamish_nospam@yahoo.com>:
Hamish:
> > ps.map now has an optional 'border' instruction to control the
> > existence, color, and width of the box around the map area.Paul:
> That's great! Will be a godsend to someone somewhere I'm sure.The next step is to write a wxPython GUI cartographic composer frontend
which will create a ps.map instructions file and run that to create a
PostScript file. ps.map can make very professional hardcopy maps, but it
needs a user friendly front-end.see
http://grass.gdf-hannover.de/wiki/GRASS_GUI#ComponentsThere was a TclTk start for this in d.m, gui/tcltk/d.m/print.tcl.
This is not meant replace a Print button for the current display
monitor, it's a stand alone hardcopy plot generator. That print button
could write to a ps.map file, but maybe it is very easy to write
directly to PostScript from the map canvas, like Michael has done for
gis.m?
Yes, but currently what is written from the map canvas is the rasterized PNG image, not the original vector information, which makes working on the resulting ps file in a vector graphics program impossible...
As soon as new map display class will be defined in wxPython, I would
like to build georectifing, ps.map and digitizing tool on top of it.
Is there any possibility of changing the display system so that vector data is displayed as such in the display or at least the content of the display could be directly exported to ps or pdf as vector ?
Just naive questions, but this might determine whether it is better to concentrate on a ps.map frontend or on direct vector export of the display.
Moritz
hi
>> This is not meant replace a Print button for the current display
>> monitor, it's a stand alone hardcopy plot generator. That print button
>> could write to a ps.map file, but maybe it is very easy to write
>> directly to PostScript from the map canvas, like Michael has done for
>> gis.m?Yes, but currently what is written from the map canvas is the rasterized
PNG image, not the original vector information, which makes working on
the resulting ps file in a vector graphics program impossible...>
> As soon as new map display class will be defined in wxPython, I would
> like to build georectifing, ps.map and digitizing tool on top of it.
>Is there any possibility of changing the display system so that vector
data is displayed as such in the display or at least the content of the
display could be directly exported to ps or pdf as vector ?Just naive questions, but this might determine whether it is better to
concentrate on a ps.map frontend or on direct vector export of the display.Moritz
well, this puts us back to discussion about basic GUI concept. The
chosen one, Python+some graphical library (currently wxWidgets) stands
for
* fast development
* more people able to help with the development: it will be always
easier to learn python, then C(++) and it's usage together with
Qt/wxWdigets/Gtk+/...
but there are also some disadvantages:
* the gui will be never as fast as compiled one
* since there is no properly working swig interface, it would be very
difficult to access raster and vector data with help of Python. But it
would be very difficult to rewrite whole d.vect module in any other
language.
I would say, if we would need to rewrite Map Displays so they access
raster and vector files directly, we would need to code this parts in
C. It would take us too much time IMHO.
My imagination is, to use Map Display with pop-up tool bar(s) for
specific tools -- if there is someone, who disagrees with this point,
please raise your hand. ps.map is very good tool for creation of
hard-copy maps. It should not be too big task to add tool, which would
generate configuration file for ps.map based on map display content.
For the future, it would be good to improve d.vect to be able to
display e.g. dashed lines and so on and to improve ps.map so it is
possible to work with multiple raster tiles and so on.
Just my 2 cents
Jachym
--
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
On 08/02/07 10:52, Jáchym Čepický wrote:
hi
>> This is not meant replace a Print button for the current display
>> monitor, it's a stand alone hardcopy plot generator. That print button
>> could write to a ps.map file, but maybe it is very easy to write
>> directly to PostScript from the map canvas, like Michael has done for
>> gis.m?Yes, but currently what is written from the map canvas is the rasterized
PNG image, not the original vector information, which makes working on
the resulting ps file in a vector graphics program impossible...>
> As soon as new map display class will be defined in wxPython, I would
> like to build georectifing, ps.map and digitizing tool on top of it.
>Is there any possibility of changing the display system so that vector
data is displayed as such in the display or at least the content of the
display could be directly exported to ps or pdf as vector ?Just naive questions, but this might determine whether it is better to
concentrate on a ps.map frontend or on direct vector export of the display.Moritz
well, this puts us back to discussion about basic GUI concept. The
chosen one, Python+some graphical library (currently wxWidgets) stands
for* fast development
* more people able to help with the development: it will be always
easier to learn python, then C(++) and it's usage together with
Qt/wxWdigets/Gtk+/...but there are also some disadvantages:
* the gui will be never as fast as compiled one
* since there is no properly working swig interface, it would be very
difficult to access raster and vector data with help of Python. But it
would be very difficult to rewrite whole d.vect module in any other
language.I would say, if we would need to rewrite Map Displays so they access
raster and vector files directly, we would need to code this parts in
C. It would take us too much time IMHO.My imagination is, to use Map Display with pop-up tool bar(s) for
specific tools -- if there is someone, who disagrees with this point,
please raise your hand. ps.map is very good tool for creation of
hard-copy maps. It should not be too big task to add tool, which would
generate configuration file for ps.map based on map display content.For the future, it would be good to improve d.vect to be able to
display e.g. dashed lines and so on and to improve ps.map so it is
possible to work with multiple raster tiles and so on.
Glynn has mentioned reflections on rewriting the whole display architecture (see http://grass.itc.it/pipermail/grass5/2006-May/023325.html). But I agree that until this is done, advancing with the combination of PNG/PPM displayed in map canvas + ps.map for output is probably the best solution.
I also agree that ps.map needs a series of improvements[1] to make it really good for cartography...but I know that it's up to me to make them 
Moritz
[1] one example: at this stage proportionate symbols are not drawn in descending order of size, thus potentially hiding smaller symbols. I corrected that in the new version of d.vect.chart I proposed, but it is still an issue in ps.map. This gets even more complicated when you want to add a color scheme to that as you have to use a separate vpoints command for each color and making sorting symbols by size almost impossible, but allowing the use of the RGB column in ps.map would solve that (I remember there being mails about this latter issue, but can't find them now).
Maybe not a fundamental issue for most, but a show stopper for adopting GRASS as the main GIS and cartography tool here in my department where a lot of proportionate symbol maps are drawn.
Jáchym Èepický wrote:
As soon as new map display class will be defined in wxPython, I would
like to build georectifing, ps.map and digitizing tool on top of it.
Great!
Michael is currently working on it. We are using wxPython 2.8, and
there are small problems with this version on debian-based distros
(compilation works well, but the packaging system does not like some
definitions).
:-/
I was waiting for Debian/Etch to give it a try. That will ship with wx
2.6.3 (c.July 2006), so that will still not be enough? Is 2.8 full of
goodies that the earlier versions from 6 months ago lack?
* since there is no properly working swig interface, it would be very
difficult to access raster and vector data with help of Python.
If we will be doing heavy Python GUI programming it seems obvious to
spend some time at the beginning getting the swig interface working
properly, if currently it isn't. That would save us a lot of pain in the
long run.
Hamish
Moritz Lennert wrote:
> As soon as new map display class will be defined in wxPython, I would
> like to build georectifing, ps.map and digitizing tool on top of it.Is there any possibility of changing the display system so that vector
data is displayed as such in the display or at least the content of the
display could be directly exported to ps or pdf as vector ?
No. At least, not in the short/medium term.
You're talking about a completely new display architecture. The
current architecture is entirely unsuitable for writing a
PostScript/PDF/SVG/etc "driver".
Note that any display architecture which *was* suitable for generating
PostScript/etc output would be rule out the use of G_plot_polygon()
etc for rendering, so d.vect would need to be fixed.
--
Glynn Clements <glynn@gclements.plus.com>
Hamish wrote on 02/08/2007 12:45 PM:
Jáchym Èepický wrote:
...* since there is no properly working swig interface, it would be very
difficult to access raster and vector data with help of Python.
If we will be doing heavy Python GUI programming it seems obvious to
spend some time at the beginning getting the swig interface working
properly, if currently it isn't. That would save us a lot of pain in the
long run.
I still hope that Alessandro Frigeri submits his patches for the
SWIG interface such as session management and so forth (he
presented it at the last year's Lausanne conference).
It would be a waste of time to re-invent that again.
markus
Here is a bit of information that might be helpful in looking ahead. TclTk
does indeed have vector drawing that **could** replace the current d.vect
rasterized display, at least for digitizing and quite possibly for display
too. Something along the lines of v.edit could utilize this.
However, I'd really like to push ahead with wx.Python instead of spending
more time on TclTk since we've decided to abandon that venerable platform.
The newest version of wx.Python (2.8) has a couple different modules that
support true vector objects rather than just rasterized displays (this was
more of an issue with version 2.6 and below). I don't yet know which would
work better for GRASS vectors, but if we can make use of them, it will
provide much better looking vector output and digitizing.
Nevertheless, a cartographic module is a different beast from the kinds of
working displays we have now. Building on ps.map might well be the best
avenue to take with this, since much of the coding has been done and it can
be controlled by commands and scripts.
As someone just said, the old dm TclTk print module was an early start in
that direction.
Michael
On 2/8/07 2:52 AM, "Jáchym Èepický" <jachym.cepicky@gmail.com> wrote:
My imagination is, to use Map Display with pop-up tool bar(s) for
specific tools -- if there is someone, who disagrees with this point,
please raise your hand. ps.map is very good tool for creation of
hard-copy maps. It should not be too big task to add tool, which would
generate configuration file for ps.map based on map display content.For the future, it would be good to improve d.vect to be able to
display e.g. dashed lines and so on and to improve ps.map so it is
possible to work with multiple raster tiles and so on.
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
On Thursday 08 February 2007 03:48, Glynn Clements wrote:
Moritz Lennert wrote:
> > As soon as new map display class will be defined in wxPython, I would
> > like to build georectifing, ps.map and digitizing tool on top of it.
>
> Is there any possibility of changing the display system so that vector
> data is displayed as such in the display or at least the content of the
> display could be directly exported to ps or pdf as vector ?No. At least, not in the short/medium term.
You're talking about a completely new display architecture. The
current architecture is entirely unsuitable for writing a
PostScript/PDF/SVG/etc "driver".Note that any display architecture which *was* suitable for generating
PostScript/etc output would be rule out the use of G_plot_polygon()
etc for rendering, so d.vect would need to be fixed.
Having specialized output drivers seems like it might help retain CLI
functionality _and_ potential to create high quality output. Using R as an
example:
# plot something to the screen, low res but functional
x11()
plot(x, y, ...)
# plot something to a PDF file: nice crisp lines, etc.
pdf(file='new.pdf', width=6, height=10)
plot(x, y, ...
# close the file
dev.off()
This approach allows the same commands to draw on the screen or out to any
number of files:
png() , postscript(), pdf(), fig(), ... you get the idea
Generalizing the d.* commands sufficiently would be the challenge... it would
be a great improvement to just output an Xmon to PDF - with real vector
representation of lines, etc.
Just some thoughts,
Cheers,
--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341
Je-Báchym Èepický wrote:e-A
* the gui will be never as fast as compiled one
Unless the GUI is going to do its own rendering, that isn't really an
issue.
I would say, if we would need to rewrite Map Displays so they access
raster and vector files directly, we would need to code this parts in
C. It would take us too much time IMHO.
I would caution against that.
The GRASS API was designed for traditional one-shot utilities; it is
entirely unsuited to persistent applications such as a GUI. E.g.:
1. If anything unexpected occurs, the usual response is to call
G_fatal_error(), which terminates the process.
2. The core libraries have many global variables, which are
initialised either by the loader at program startup, by G_gisinit(),
or on first access. In many (most?) cases, there is no way to reset
the library state back to its initial state.
My imagination is, to use Map Display with pop-up tool bar(s) for
specific tools -- if there is someone, who disagrees with this point,
please raise your hand. ps.map is very good tool for creation of
hard-copy maps. It should not be too big task to add tool, which would
generate configuration file for ps.map based on map display content.For the future, it would be good to improve d.vect to be able to
display e.g. dashed lines
That's an architectural change. I really don't want to see the
existing graphics system (libraster etc) improved. It's long overdue
to be replaced with something better. Unfortunately, the problem with
a better API is that it's the interface which needs to change, rather
than just the implementation. And that involves re-writing a lot of
d.* modules.
and so on and to improve ps.map so it is possible to work with
multiple raster tiles and so on.
Are you talking about overlaying raster maps? One thing to bear in
mind here is that you need level 3 PostScript for masked images
(images with transparent pixels), and there are plenty of printers out
there which don't support level 3.
--
Glynn Clements <glynn@gclements.plus.com>
Something I proposed is that we really limit the number of d.* modules used
in the new GUI. All the decorations (e.g., scale, north arrows, text,
histogram, maybe grids or others) would be better done within wx.Python
rather than rendered into raster maps by a d.* module as they are now. They
would look much better and offer greater flexibility in placement options
and appearance. I'm not proposing that we get rid of such modules, just not
use them in the new GUI. That would reduce the amount of d.* module
rewriting needed perhaps.
Michael
On 2/8/07 1:28 PM, "Glynn Clements" <glynn@gclements.plus.com> wrote:
Je-Báchym Èepický wrote:e-A
* the gui will be never as fast as compiled one
Unless the GUI is going to do its own rendering, that isn't really an
issue.I would say, if we would need to rewrite Map Displays so they access
raster and vector files directly, we would need to code this parts in
C. It would take us too much time IMHO.I would caution against that.
The GRASS API was designed for traditional one-shot utilities; it is
entirely unsuited to persistent applications such as a GUI. E.g.:1. If anything unexpected occurs, the usual response is to call
G_fatal_error(), which terminates the process.2. The core libraries have many global variables, which are
initialised either by the loader at program startup, by G_gisinit(),
or on first access. In many (most?) cases, there is no way to reset
the library state back to its initial state.My imagination is, to use Map Display with pop-up tool bar(s) for
specific tools -- if there is someone, who disagrees with this point,
please raise your hand. ps.map is very good tool for creation of
hard-copy maps. It should not be too big task to add tool, which would
generate configuration file for ps.map based on map display content.For the future, it would be good to improve d.vect to be able to
display e.g. dashed linesThat's an architectural change. I really don't want to see the
existing graphics system (libraster etc) improved. It's long overdue
to be replaced with something better. Unfortunately, the problem with
a better API is that it's the interface which needs to change, rather
than just the implementation. And that involves re-writing a lot of
d.* modules.and so on and to improve ps.map so it is possible to work with
multiple raster tiles and so on.Are you talking about overlaying raster maps? One thing to bear in
mind here is that you need level 3 PostScript for masked images
(images with transparent pixels), and there are plenty of printers out
there which don't support level 3.
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
2007/2/8, Glynn Clements <glynn@gclements.plus.com>:
>
> For the future, it would be good to improve d.vect to be able to
> display e.g. dashed linesThat's an architectural change. I really don't want to see the
existing graphics system (libraster etc) improved. It's long overdue
to be replaced with something better. Unfortunately, the problem with
a better API is that it's the interface which needs to change, rather
than just the implementation. And that involves re-writing a lot of
d.* modules.
well, I was only thinking on easier coding of GUI for ps.map, so that
the user could see the preview of the result.
> and so on and to improve ps.map so it is possible to work with
> multiple raster tiles and so on.Are you talking about overlaying raster maps? One thing to bear in
mind here is that you need level 3 PostScript for masked images
(images with transparent pixels), and there are plenty of printers out
there which don't support level 3.
no, but IIRC if you have multiple backdrop raster maps ordered into
tiles, you have to patch them (using r.patch). if ps.map would be able
to work with multiple not-overlaying raster maps, this step would not
be necessary.
myhcaj
--
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
Michael Barton wrote:
Something I proposed is that we really limit the number of d.* modules used
in the new GUI. All the decorations (e.g., scale, north arrows, text,
histogram, maybe grids or others) would be better done within wx.Python
rather than rendered into raster maps by a d.* module as they are now. They
would look much better and offer greater flexibility in placement options
and appearance. I'm not proposing that we get rid of such modules, just not
use them in the new GUI. That would reduce the amount of d.* module
rewriting needed perhaps.
d.* aren't just for interactive use. Any new architecture needs to
allow for scripted creation of graphics (e.g. web applications).
BTW, there are two distinct types of graphics: georeferenced and not.
Of the above examples, all but histograms are georeferenced (or may
be; text can be either). Having graphics generated by two different
mechanisms would require some effort to ensure that "annotations"
actually aligned with the maps.
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements wrote:
Michael Barton wrote:
> Something I proposed is that we really limit the number of d.*
> modules used in the new GUI. All the decorations (e.g., scale, north
> arrows, text, histogram, maybe grids or others) would be better done
> within wx.Python rather than rendered into raster maps by a d.*
> module as they are now. They would look much better and offer
> greater flexibility in placement options and appearance. I'm not
> proposing that we get rid of such modules, just not use them in the
> new GUI. That would reduce the amount of d.* module rewriting needed
> perhaps.d.* aren't just for interactive use. Any new architecture needs to
allow for scripted creation of graphics (e.g. web applications).BTW, there are two distinct types of graphics: georeferenced and not.
Of the above examples, all but histograms are georeferenced (or may
be; text can be either). Having graphics generated by two different
mechanisms would require some effort to ensure that "annotations"
actually aligned with the maps.
FYI, "d.barscale -n" is not georeferenced, either is d.graph (without
the -m flag). d.graph can be used for scripted creation of graphics;
perhaps not as efficiently as direct calls, but I don't think it is so
slow either. Certainly it is flexible. (I'm not arguing to use it for
the GUI, I'm just pointing out that it exists and could help with
prototypes)
Hamish
On 2/8/07 6:37 PM, "Glynn Clements" <glynn@gclements.plus.com> wrote:
Michael Barton wrote:
Something I proposed is that we really limit the number of d.* modules used
in the new GUI. All the decorations (e.g., scale, north arrows, text,
histogram, maybe grids or others) would be better done within wx.Python
rather than rendered into raster maps by a d.* module as they are now. They
would look much better and offer greater flexibility in placement options
and appearance. I'm not proposing that we get rid of such modules, just not
use them in the new GUI. That would reduce the amount of d.* module
rewriting needed perhaps.d.* aren't just for interactive use. Any new architecture needs to
allow for scripted creation of graphics (e.g. web applications).
Indeed. That's why I don't propose we get rid of them.
BTW, there are two distinct types of graphics: georeferenced and not.
Of the above examples, all but histograms are georeferenced (or may
be; text can be either). Having graphics generated by two different
mechanisms would require some effort to ensure that "annotations"
actually aligned with the maps.
I'm not sure that it's important to have scales and north arrows
georeferenced. Some may disagree of course. But scales were georeferenced in
earlier versions of MapInfo and I always thought it was a pain.
Georeferencing of some text is indeed important. Vector labels are the best
example. But these are created from a text file generated by v.label. I've
already got a simple example in TclTk of how such a file can be parsed into
labels generated by the GUI. Doing something like contour labels would be
nice, but we don't have a particularly good way to do that now by any method
(a "contour" setting for v.label might be nice).
Grids are georeferenced of course. The ones we have are pretty nice, but it
wouldn't be that hard to generate them in the GUI since it is necessary to
track earth coordinates for region setting of the display anyway. This would
allow more control over stroke form, width, and color, as well as grid label
placement.
An RGB/HIS display seems like it needs to stay as a layer. Cell numbers and
arrows might be better wrapped into the raster control in the GUI, even if
they remain separate d.* modules.
Thematic maps and charts seem like they should be a vector option rather
than separate layers. This could be done with GUI code without needing to
combine the d.* modules. However, if we did true vector rendering for
primitives, we'd want the same quality in thematic maps and charts.
I'm not sure if this makes any considered recoding any easier or not. But
the upshot is that vector primitives, thematic maps, and charts seem the
best candidates for some reworking of the C code for display. Most of the
other d.* effects can work with current code or be replaced by GUI generated
graphics if we want. As you point out, this is more work at the GUI coding
end. I'm not sure which will take more effort.
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Moritz Lennert wrote:
[1] one example: at this stage proportionate symbols are not drawn in
descending order of size, thus potentially hiding smaller symbols. I
corrected that in the new version of d.vect.chart I proposed, but it
is still an issue in ps.map. This gets even more complicated when you
want to add a color scheme to that as you have to use a separate
vpoints command for each color and making sorting symbols by size
almost impossible, but allowing the use of the RGB column in ps.map
would solve that (I remember there being mails about this latter
issue, but can't find them now).
Maybe not a fundamental issue for most, but a show stopper for
adopting GRASS as the main GIS and cartography tool here in my
department where a lot of proportionate symbol maps are drawn.
http://intevation.de/rt/webrt?serial_num=5129
What about cases like Markus's PHP earthquake map, where you want the
new big symbols to be drawn on top of older ones? If automatically
sorted, there is no way to unsort them in cases when that is more
appropriate.
work-around 1) fillcolor = none
work-around 2) border color = none. Then all are equal depth 
work-around 3) things are drawn by their cat #, so add a column,
populate it with a ranking, and then use v.reclass column= to use them
as cat numbers.
Support for GRASSRGB in ps.map is wish #3299.
Hamish
Michael Barton wrote:
Doing something like contour labels would be nice, but we don't have a
particularly good way to do that now by any method (a "contour"
setting for v.label might be nice).
My experience with auto-placed contour labels in Surfer and Matlab has
left me fairly unimpressed. Maybe GMT has something better.
Idea to do it in GRASS:
v.to.points dmax= + "d.vect disp=attr" or "v.labels -a" for rotation.
Maybe GRASS 5's d.vect.labels could? I can't remember.
Hamish