[GRASS-dev] Profiler updates

GRASS GIS GRASS GIS developer
1

Maris,

I committed your patch to profile.tcl with a few modifications. The window placement is a nice improvement. There was already an error trap for profiles with a 0 length, so I deleted your 2nd trap for this condition. I also moved the trap for elevation range = 0 up a bit to immediately after the spot where the procedure for generating elevation range is called.

I thought of another potential problem but haven’t found a way to trap it. If you send r.profile any coordinates that extend beyond the current region, it will crash and crash the entire GUI—in spite of the fact that the call to r.profile is trapped with a catch statement. The profiler generates correct coordinates for any place on the display, regardless of whether it extends beyond the region boundaries or not. However, r.profile apparently chokes on coordinates outside the region.

I’m not sure if this can really be called a bug in r.profile, but it should probably fail more gracefully.

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

2

Michael Barton wrote:

I committed your patch to profile.tcl with a few modifications. The
window placement is a nice improvement. There was already an error
trap for profiles with a 0 length, so I deleted your 2nd trap for this
condition. I also moved the trap for elevation range = 0 up a bit to
immediately after the spot where the procedure for generating
elevation range is called.

I thought of another potential problem but haven¹t found a way to trap
it. If you send r.profile any coordinates that extend beyond the
current region, it will crash and crash the entire GUI‹in spite of the
fact that the call to r.profile is trapped with a catch statement. The
profiler generates correct coordinates for any place on the display,
regardless of whether it extends beyond the region boundaries or not.
However, r.profile apparently chokes on coordinates outside the
region.

I¹m not sure if this can really be called a bug in r.profile, but it
should probably fail more gracefully.

This is a bug in r.profile. Out of region values are not correct.

spearfish example:

d.mon x0
# stretch the window so it is twice as wide as it is tall
g.region rast=elevation.dem
d.erase color=grey
d.rast elevation.dem
r.profile -i in=elevation.dem res=300

If you go off the left edge of the region, the answers are wrong.
If you go off the right edge, the answers are very wrong, then 0.

# next re-strech the window so it is taller that wide.

If you go off the bottom:
WARNING: [elevation.dem in PERMANENT] - read request for row 471 is
    outside region
and a the program exits.

If you go off the top:
ERROR: Coordinate request outsite current region settings
and a the program exits.

d.what.rast gives a "You are clicking outside the map" warning.

r.what gives a warning before reporting a NULL ("*"):

G63> r.what in=elevation.dem east_north=602283,4913294
** note ** 602283 4913294 is outside your current window
602283|4913294||*

So it would seem appropriate that r.profile out-of-region should report
a "NULL" result (to stdout) and warning that the endpoint is out of
region (G_warning() to stderr).

Hamish

3

This sounds like a good assessment and suggestion.

Michael

On 2/11/07 9:20 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:

Michael Barton wrote:

I committed your patch to profile.tcl with a few modifications. The
window placement is a nice improvement. There was already an error
trap for profiles with a 0 length, so I deleted your 2nd trap for this
condition. I also moved the trap for elevation range = 0 up a bit to
immediately after the spot where the procedure for generating
elevation range is called.

I thought of another potential problem but haven¹t found a way to trap
it. If you send r.profile any coordinates that extend beyond the
current region, it will crash and crash the entire GUI‹in spite of the
fact that the call to r.profile is trapped with a catch statement. The
profiler generates correct coordinates for any place on the display,
regardless of whether it extends beyond the region boundaries or not.
However, r.profile apparently chokes on coordinates outside the
region.

I¹m not sure if this can really be called a bug in r.profile, but it
should probably fail more gracefully.

This is a bug in r.profile. Out of region values are not correct.

spearfish example:

d.mon x0
# stretch the window so it is twice as wide as it is tall
g.region rast=elevation.dem
d.erase color=grey
d.rast elevation.dem
r.profile -i in=elevation.dem res=300

If you go off the left edge of the region, the answers are wrong.
If you go off the right edge, the answers are very wrong, then 0.

# next re-strech the window so it is taller that wide.

If you go off the bottom:
WARNING: [elevation.dem in PERMANENT] - read request for row 471 is
outside region
and a the program exits.

If you go off the top:
ERROR: Coordinate request outsite current region settings
and a the program exits.

d.what.rast gives a "You are clicking outside the map" warning.

r.what gives a warning before reporting a NULL ("*"):

G63> r.what in=elevation.dem east_north=602283,4913294
** note ** 602283 4913294 is outside your current window
602283|4913294||*

So it would seem appropriate that r.profile out-of-region should report
a "NULL" result (to stdout) and warning that the endpoint is out of
region (G_warning() to stderr).

Hamish

__________________________________________
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

4

Michael Barton wrote:
> I thought of another potential problem but haven¹t found a way to
> trap it. If you send r.profile any coordinates that extend beyond
> the current region, it will crash and crash the entire GUI in spite
> of the fact that the call to r.profile is trapped with a catch
> statement. The profiler generates correct coordinates for any place
> on the display, regardless of whether it extends beyond the region
> boundaries or not. However, r.profile apparently chokes on
> coordinates outside the region.
>
> I¹m not sure if this can really be called a bug in r.profile, but it
> should probably fail more gracefully.

Hamish:

This is a bug in r.profile. Out of region values are not correct.

fixed in 6.2 and 6.3 cvs.

Now it exits with G_fatal_error() if a coordinate is outside of the
current region. (exit code 1)

gis.m still doesn't catch this, and dies with a "child process exited
abnormally" error. But at least it no longer outputs garbage data.

r.profile out-of-region should report a "NULL" result (to stdout) and
warning that the endpoint is out of region (G_warning() to stderr).

up for discussion. harder to do.

Hamish

5

Hi gis.m bug fighters, comments inline.

2007/2/13, Hamish <hamish_nospam@yahoo.com>:

Hamish:
> This is a bug in r.profile. Out of region values are not correct.

fixed in 6.2 and 6.3 cvs.

Now it exits with G_fatal_error() if a coordinate is outside of the
current region. (exit code 1)

gis.m still doesn't catch this, and dies with a "child process exited
abnormally" error. But at least it no longer outputs garbage data.

This should be fixed before 6.3.

> r.profile out-of-region should report a "NULL" result (to stdout) and
> warning that the endpoint is out of region (G_warning() to stderr).

up for discussion. harder to do.

IMHO we should better fix gis.m from working OUTSIDE region. I'm not
as good in tcl/tk to send patch, but just questions:
* would it be possible to resize drawable area to region in gis.m
display? (one way how to deal with user working outside of defined
region)
* or maybee we should add region boundary checking in measure/query
tools? Then only question is - what to do if user HAS clicked outside
region?

Hamish

I care about gis.m cause IMHO till next stable release new GUI will
NOT be production ready and gis.m is really good, we should just make
it also user frendly and foolproof to provide excelent UI expierience.

Maris.

6

The reason that the profiler can get coordinates from outside the region is
that it is possible, using the zoom box tool, to create a region whose
geometry does not exactly match the geometry of the display window. There
are good and bad sides to this (the profile issue being one of bads,
apparently), but it is a function of GRASS's sophisticated region setting
abilities--i.e., these are not inherently tied to visualization and do
affect computations. Initially a pain for users accustomed to other
programs, most people come to appreciate the power of GRASS's region
management features...eventually. :wink:

So much for background. It is of course possible to do something to alert
the user when the profiling cursor strays outside region boundaries. But
most such 'solutions' I can imagine could easily get very annoying for
interactive use. (Maybe I'll have better imagination later today after a
couple cups of coffee)

IMHO, r.profile should simply report NULL values for any coordinates that
fall outside the region--like many other tools that return information about
raster cells. This could easily be trapped and dealt with in the profiler.
Unfortunately, Hamish indicates that this is difficult to implement.

Michael

On 2/13/07 1:26 AM, "Maris Nartiss" <maris.gis@gmail.com> wrote:

Hi gis.m bug fighters, comments inline.

2007/2/13, Hamish <hamish_nospam@yahoo.com>:

Hamish:

This is a bug in r.profile. Out of region values are not correct.

fixed in 6.2 and 6.3 cvs.

Now it exits with G_fatal_error() if a coordinate is outside of the
current region. (exit code 1)

gis.m still doesn't catch this, and dies with a "child process exited
abnormally" error. But at least it no longer outputs garbage data.

This should be fixed before 6.3.

r.profile out-of-region should report a "NULL" result (to stdout) and
warning that the endpoint is out of region (G_warning() to stderr).

up for discussion. harder to do.

IMHO we should better fix gis.m from working OUTSIDE region. I'm not
as good in tcl/tk to send patch, but just questions:
* would it be possible to resize drawable area to region in gis.m
display? (one way how to deal with user working outside of defined
region)
* or maybee we should add region boundary checking in measure/query
tools? Then only question is - what to do if user HAS clicked outside
region?

Hamish

I care about gis.m cause IMHO till next stable release new GUI will
NOT be production ready and gis.m is really good, we should just make
it also user frendly and foolproof to provide excelent UI expierience.

Maris.

__________________________________________
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

7

Maris,

I strongly second this, and want to thank you for all your recent work to
this end. I'd like to have the current GUI solid and reliable enough to last
for 6-12 months while we work out the new wx.Python. I have no idea how long
it will take, and may move faster if more people work on it. However, given
my experience in doing the TclTk GUI, I don't want to underestimate the time
needed to develop a good interface. And the TclTk interface needs to be as
solid as possible in the interim.

Michael

On 2/13/07 1:26 AM, "Maris Nartiss" <maris.gis@gmail.com> wrote:

I care about gis.m cause IMHO till next stable release new GUI will
NOT be production ready and gis.m is really good, we should just make
it also user frendly and foolproof to provide excelent UI expierience.

__________________________________________
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

8

Hamish:

>>> r.profile out-of-region should report a "NULL" result (to stdout)
>>> and warning that the endpoint is out of region (G_warning() to
>>> stderr). up for discussion. harder to do.

Maris:

> IMHO we should better fix gis.m from working OUTSIDE region.

Michael wrote:

IMHO, r.profile should simply report NULL values for any coordinates
that fall outside the region--like many other tools that return
information about raster cells. This could easily be trapped and dealt
with in the profiler. Unfortunately, Hamish indicates that this is
difficult to implement.

Just "harder to do", but not super difficult. I think I agree that out-
of-region shouldn't G_fatal_error(), so I'll work on it.

Example: you use a fixed transect line and apply it to different maps
with different spatial coverage. Off the end of a map is an unknown
value, which is typically represented by a NULL.

Hamish:

>> Now it exits with G_fatal_error() if a coordinate is outside of the
>> current region. (exit code 1)
>>
>> gis.m still doesn't catch this, and dies with a "child process
>> exited abnormally" error. But at least it no longer outputs garbage
>> data.

Even if I have it report NULLs instead of exit with an error this
problem will remain and anytime r.profile exits abnormally it will bring
down all of gis.m. So we should figure out why this is happening and fit
it as well -- the same bug & fragility may exist in many other places
too.

Hamish

9

Michael wrote:

r.profile should simply report NULL values for any coordinates
that fall outside the region--like many other tools that return
information about raster cells.

Done in 6.3-cvs. It is too invasive to backport to 6.2, so you should
still try and figure out why gis.m crashes if r.profile exits with a
fatal error. (in 6.2-cvs it now fatal errors instead of returning
incorrect results)

This could easily be trapped and dealt with in the profiler.

Currently the profile line interpolates over areas of null value.
It would be more correct if the line stopped and then restarted
when the data resumed. e.g.:

  http://bambi.otago.ac.nz/hamish/grass/profile_nulls.png

wish 1: prettify max value on x-axis:

Index: profile.tcl

RCS file:
/home/grass/grassrepository/grass6/gui/tcltk/gis.m/profile.tcl,v
retrieving revision 1.13
diff -u -r1.13 profile.tcl
--- profile.tcl 11 Feb 2007 23:58:53 -0000 1.13
+++ profile.tcl 14 Feb 2007 04:20:06 -0000
@@ -494,7 +494,7 @@
        
        # add label for total transect distance
        $pcan create text $right $xscaletop \
- -text "$cumdist" \
+ -text "[format %g $cumdist]" \
                -anchor n \
                -justify center

perhaps do the same for x-axis min/max?
(are the double-quotes around redundant?)

wish 2: add units to the axes.
# x-axis: r.profile always return meters
# y-axis get units (plural) from g.proj:
g.proj -p | grep '^units' | cut -f2 -d: | awk '{print $1}'
* probably want to do that in Tcl not with unix utils :slight_smile: + rotate 90 deg.
* nice example of where Python SWIG interface to libgis will be useful.
   Instead of running all of g.proj + parsing you could just get the
   value directly via G_database_unit_name(1). (1==plural)

wish 3: write distance labels for ticks along the x-axis.
I'm not sure how to guarantee that they won't overlap if too close
together.

also-- the display manager is ignoring the color rule for NULL.

For that screenshot I had set up color rules like this:

G63> r.colors elevation.dem col=rules << EOF
nv red
0% green
50% yellow
100% blue
EOF

in a xmon you see the NULL slivers are red, but in the display manager
they are white.

Hamish

10

This one is easy I think. The map display by default sets nulls to
transparent for better display of overlaid raster maps. There is a check box
to change this.

Michael

On 2/13/07 9:47 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:

also-- the display manager is ignoring the color rule for NULL.

For that screenshot I had set up color rules like this:

G63> r.colors elevation.dem col=rules << EOF
nv red
0% green
50% yellow
100% blue
EOF

__________________________________________
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

11

H:

> also-- the display manager is ignoring the color rule for NULL.
>
> For that screenshot I had set up color rules like this:
>
> G63> r.colors elevation.dem col=rules << EOF
> nv red
> 0% green
> 50% yellow
> 100% blue
> EOF

Michael wrote:

This one is easy I think. The map display by default sets nulls to
transparent for better display of overlaid raster maps. There is a
check box to change this.

Ok, I see it. -If overlay is not checked- the pulldown menu lets you
pick the color used for null.

So gis.m does ignore the value in the colr table for "nv", but it gives
you another way to manually set it. This is a bug, the pulldown list
needs either an entry for "none", or "Set background color" in the GIS
manager's raster panel needs a checkbox before it to make d.rast's "bg="
an optional term, as it is on the command line. But a fairly minor bug.

Hamish

12

Hamish,

See below.

On 2/13/07 10:45 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:

H:

also-- the display manager is ignoring the color rule for NULL.

For that screenshot I had set up color rules like this:

G63> r.colors elevation.dem col=rules << EOF
nv red
0% green
50% yellow
100% blue
EOF

Michael wrote:

This one is easy I think. The map display by default sets nulls to
transparent for better display of overlaid raster maps. There is a
check box to change this.

Ok, I see it. -If overlay is not checked- the pulldown menu lets you
pick the color used for null.

So gis.m does ignore the value in the colr table for "nv", but it gives
you another way to manually set it. This is a bug, the pulldown list
needs either an entry for "none", or "Set background color" in the GIS
manager's raster panel needs a checkbox before it to make d.rast's "bg="
an optional term, as it is on the command line. But a fairly minor bug.

The GUI only runs d.rast with its options in this case. The default is
d.rast -o (because it seemed that most of the times people would prefer to
run it in overlay mode). The command passed to the shell is...

D.rast -o map=elevation.10m

Unchecking the box simply turns off the -o flag. The bg option is only set
if you pick a color. Otherwise it is simply not included in the command
passed to the shell. For example, if you unselect the overlay checkbox and
don't pick a background color, the command passed to the shell is...

D.rast map=elevation.10m

Also, there is no "none" color allowed for the bg=[color] option. When I
tried it, I got...

D.rast map=elevation.10m bg=none

Error: value <none> out of range for parameter <bg>
       Legal range:
white,black,red,green,blue,yellow,magenta,cyan,aqua,grey,gray,orange,brown,p
urple,violet,indigo

I don't know any other way to parse d.rast to display what you are trying to
display. Sorry.

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

13

At the moment, I'm unsuccessful in recompiling GRASS with the new cvs
download. I'll have to try again in a bit.

Michael

On 2/13/07 9:47 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:

Michael wrote:

r.profile should simply report NULL values for any coordinates
that fall outside the region--like many other tools that return
information about raster cells.

Done in 6.3-cvs. It is too invasive to backport to 6.2, so you should
still try and figure out why gis.m crashes if r.profile exits with a
fatal error. (in 6.2-cvs it now fatal errors instead of returning
incorrect results)

This could easily be trapped and dealt with in the profiler.

Currently the profile line interpolates over areas of null value.
It would be more correct if the line stopped and then restarted
when the data resumed. e.g.:

  http://bambi.otago.ac.nz/hamish/grass/profile_nulls.png

wish 1: prettify max value on x-axis:

Index: profile.tcl

RCS file:
/home/grass/grassrepository/grass6/gui/tcltk/gis.m/profile.tcl,v
retrieving revision 1.13
diff -u -r1.13 profile.tcl
--- profile.tcl 11 Feb 2007 23:58:53 -0000 1.13
+++ profile.tcl 14 Feb 2007 04:20:06 -0000
@@ -494,7 +494,7 @@
        
        # add label for total transect distance
        $pcan create text $right $xscaletop \
- -text "$cumdist" \
+ -text "[format %g $cumdist]" \
                -anchor n \
                -justify center

perhaps do the same for x-axis min/max?
(are the double-quotes around redundant?)

wish 2: add units to the axes.
# x-axis: r.profile always return meters
# y-axis get units (plural) from g.proj:
g.proj -p | grep '^units' | cut -f2 -d: | awk '{print $1}'
* probably want to do that in Tcl not with unix utils :slight_smile: + rotate 90 deg.
* nice example of where Python SWIG interface to libgis will be useful.
   Instead of running all of g.proj + parsing you could just get the
   value directly via G_database_unit_name(1). (1==plural)

wish 3: write distance labels for ticks along the x-axis.
I'm not sure how to guarantee that they won't overlap if too close
together.

also-- the display manager is ignoring the color rule for NULL.

For that screenshot I had set up color rules like this:

G63> r.colors elevation.dem col=rules << EOF
nv red
0% green
50% yellow
100% blue
EOF

in a xmon you see the NULL slivers are red, but in the display manager
they are white.

Hamish

__________________________________________
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

14

Hamish:

>>> also-- the display manager is ignoring the color rule for NULL.

Michael:

The GUI only runs d.rast with its options in this case. The default is
d.rast -o (because it seemed that most of the times people would
prefer to run it in overlay mode). The command passed to the shell
is...

D.rast -o map=elevation.10m

Unchecking the box simply turns off the -o flag. The bg option is only
set if you pick a color. Otherwise it is simply not included in the
command passed to the shell.

Sorry, my mistake. It works fine. I made one dumb mistake wrt -o and
fell into another tcl trap wrt color.

- obviously if you use -o overlay mode NULLs are transparent.
- I had picked a color from the drop down list, but then didn't figure
to delete the color name manually to get back to the "none" state.

Hamish

15

Hamish,

I implemented all your wishes below. Just committed it to the cvs. See what
you think. I'm to sleep now.

Michael

On 2/13/07 9:47 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:

Michael wrote:

r.profile should simply report NULL values for any coordinates
that fall outside the region--like many other tools that return
information about raster cells.

Done in 6.3-cvs. It is too invasive to backport to 6.2, so you should
still try and figure out why gis.m crashes if r.profile exits with a
fatal error. (in 6.2-cvs it now fatal errors instead of returning
incorrect results)

This could easily be trapped and dealt with in the profiler.

Currently the profile line interpolates over areas of null value.
It would be more correct if the line stopped and then restarted
when the data resumed. e.g.:

  http://bambi.otago.ac.nz/hamish/grass/profile_nulls.png

wish 1: prettify max value on x-axis:

Index: profile.tcl

RCS file:
/home/grass/grassrepository/grass6/gui/tcltk/gis.m/profile.tcl,v
retrieving revision 1.13
diff -u -r1.13 profile.tcl
--- profile.tcl 11 Feb 2007 23:58:53 -0000 1.13
+++ profile.tcl 14 Feb 2007 04:20:06 -0000
@@ -494,7 +494,7 @@
        
        # add label for total transect distance
        $pcan create text $right $xscaletop \
- -text "$cumdist" \
+ -text "[format %g $cumdist]" \
                -anchor n \
                -justify center

perhaps do the same for x-axis min/max?
(are the double-quotes around redundant?)

wish 2: add units to the axes.
# x-axis: r.profile always return meters
# y-axis get units (plural) from g.proj:
g.proj -p | grep '^units' | cut -f2 -d: | awk '{print $1}'
* probably want to do that in Tcl not with unix utils :slight_smile: + rotate 90 deg.
* nice example of where Python SWIG interface to libgis will be useful.
   Instead of running all of g.proj + parsing you could just get the
   value directly via G_database_unit_name(1). (1==plural)

wish 3: write distance labels for ticks along the x-axis.
I'm not sure how to guarantee that they won't overlap if too close
together.

also-- the display manager is ignoring the color rule for NULL.

For that screenshot I had set up color rules like this:

G63> r.colors elevation.dem col=rules << EOF
nv red
0% green
50% yellow
100% blue
EOF

in a xmon you see the NULL slivers are red, but in the display manager
they are white.

Hamish

__________________________________________
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

16

Michael Barton wrote:

I implemented all your wishes below. Just committed it to the cvs. See
what you think. I'm to sleep now.

cheers. comments follow.

Hamish wrote:

> Currently the profile line interpolates over areas of null value.
> It would be more correct if the line stopped and then restarted
> when the data resumed. e.g.:
>
> http://bambi.otago.ac.nz/hamish/grass/profile_nulls.png

this is still a problem.

> wish 1: prettify max value on x-axis:
> + -text "[format %g $cumdist]" \

maybe we want to improve on that more? set to %.2f then pass that string
through %g? ie limit to 2 decimal places and strip off .00. ??
or %.1f? %.0f?

> wish 2: add units to the axes.
> # x-axis: r.profile always return meters
> # y-axis get units (plural) from g.proj:

you are reporting the y units (from g.proj -p) on the x-axis. The
x-axis is always meters because that's what libgis returns.

For the x-axis, perhaps dist/1000 to make km if distance is >2500m?
(see crude but functional attached patch)

> wish 3: write distance labels for ticks along the x-axis.
> I'm not sure how to guarantee that they won't overlap if too close
> together.

nice.

Hamish

(attachments)

convtokm.diff (1.09 KB)

17

Hamish,

See below

On 2/19/07 3:17 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:

Hamish wrote:

Currently the profile line interpolates over areas of null value.
It would be more correct if the line stopped and then restarted
when the data resumed. e.g.:

  http://bambi.otago.ac.nz/hamish/grass/profile_nulls.png

this is still a problem.

I'm just happy it doesn't crash. But it should now be possible to see if
there is a way to get better output in such circumstances too.

wish 1: prettify max value on x-axis:
+ -text "[format %g $cumdist]" \

maybe we want to improve on that more? set to %.2f then pass that string
through %g? ie limit to 2 decimal places and strip off .00. ??
or %.1f? %.0f?

My concern is that we limit the decimal places where there needs to be many
(e.g., zooming in with locations in decimal degrees). Maybe I'm not
understanding the formatting codes.

wish 2: add units to the axes.
# x-axis: r.profile always return meters
# y-axis get units (plural) from g.proj:

you are reporting the y units (from g.proj -p) on the x-axis. The
x-axis is always meters because that's what libgis returns.

I don't think so. If I switch to a location in decimal degrees, the x-axis
label says "distance along transect (degrees)". G.proj is reporting the
horizontal units not the vertical ones.

The vertical units are determined by the nature of the map (elevation vs.
rock types for geology). This is why I decided not to put in y-axis units.

For the x-axis, perhaps dist/1000 to make km if distance is >2500m?
(see crude but functional attached patch)

This might be a nice way to make the formatting easier to read.

wish 3: write distance labels for ticks along the x-axis.
I'm not sure how to guarantee that they won't overlap if too close
together.

nice.

Thanks

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