[GRASS5] r.slope.aspect crash - libes/gis/null_data.c

[Helena]

Glynn Clements wrote:

> [CC to GRASS5]
>
> Helena wrote:
>
> > in case that you would have time to add it,
> > this is that missing color table, it is used for both pcurv and tcurv
> > - currently the output for curvatures will just give you
> > blue map, so it appears that the output is incorrect.
> > c1min is minimum value for profile curvature and c2min is minimum for tangential -
> > c1max and c2max is the same for maximums.
> > This colortable could be used also for partial derivatives output but I assume
> > that whoever runs it with that option knows what is he doing and can chenge the
> > colortable
> > himself.
>
> At present, the only colour table management performed by
> r.slope.aspect is this:
>
>         sprintf(buf, "r.colors map='%s' c=aspect",
>                 G_fully_qualified_name (aspect_name, G_mapset()));
>         system(buf);
>
> If there is supposed to be a "standard" colour table for gradient
> and/or curvature maps, it should probably go into r.colors rather than
> individual programs.

it would be very nice to have a greater selection of color tables in r.colors,
especially some histogram equalized colors and standardized color maps
for some often used maps (e.g. upslope area, which is generated by r.flow).

However, it is also good to have the color tables in the individual programs. Having
them
in the rst programs and r.flow has saved me already a lot of time and you
get a nice map right away. Some users may be confused by the output when
the standard color table is used (just try to assign it to curvatures or flowline
density or look at the accumulation map from r.watershed - all you get is blue
map and the user may not know that he is supposed to use r.color to get something
meaningful (nobody reads manuals as we all know).


> NB: the colour table in question is the following, from
> src/libes/rst_gmsl/interp_float/output2d.c:
>
>         MIN             127   0 255
>         -0.01             0   0 255
>         -0.001            0 127 255
>         -0.00001          0 255 255
>         0.0             200 255 200
>         0.00001         255 255   0
>         0.001           255 127   0
>         0.01            255   0   0
>         MAX             255   0 200
>
> Also, might it be better to map the extremes to some fixed value?

Originally I had it like that, but I changed it because it used to get out of range
easily - the curvatures can get pretty high, often just around a single point.

> It might be a good idea to have at least one standard colour table
> which *doesn't* adjust to the range of the data, to facilitate a
> common colouring scheme across multiple maps.

I use r.colors mapnew rast=mapstandard for that (and slope and aspect
color maps in rst programs are designed like that). But such color tables
would be great for r.colors.
I wonder - we already have a quite few color tables in r.color, how many
more could we add before it starts to be "too many". I can think of some
that it would be nice to have there.

> Such a colour table would have to conceptually range between +/-
> infinity (although a finite range could be useful for DEMs); r.colors
> would extract a suitable subrange by interpolating arctangents.

yes, there are maps which have known limited range (DEM, slope, aspect,
precipitation) and those where it is hard to predict so you may need to assume
inifinity to make it general enough.

Helena

>
>
> --
> Glynn Clements <glynn.clements at virgin.net>