[GRASS-dev] [GRASS GIS] #3043: Change default color table
GRASS GIS
trac at osgeo.org
Thu Jun 2 01:17:39 PDT 2016
#3043: Change default color table
--------------------------+---------------------------------------
Reporter: wenzeslaus | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: blocker | Milestone: 7.2.0
Component: Raster | Version: svn-trunk
Resolution: | Keywords: r.colors, d.rast, rainbow
CPU: Unspecified | Platform: Unspecified
--------------------------+---------------------------------------
Comment (by mlennert):
Replying to [comment:12 wenzeslaus]:
> Replying to [comment:11 mlennert]:
> > One aspect your review doesn't seem to take into account is
categorized maps. Many of the above arguments only relate to continuous,
quantitative values, not qualitative data (and the landuse map in viridis
is not very nice... ;-)),
>
> Right, I did not address them explicitly and I didn't looked at those
specifically, but most of the things apply to categorical (qualitative) as
well. Also I think that in case of categorical as well as diverging data
(e.g. difference), it is easier for user to realize that a special color
table is needed. viridis is not ideal but would work better than gray I
think.
You really do like viridis, it seems ;-)
>
> > but I guess this is impossible to detect automatically, so different
defaults for different types of maps does not make sense.
>
> Well, in the current code, there are in fact separate calls for CELL and
FCELL+DCELL (`Rast_map_is_fp()` is used). So, if we say that CELL map are
categorical, they could be separate. I'm not sure how big assumption that
would be. If CELL==categorical, separate tables would be easy to add
unless I'm missing something.
(source:grass/trunk/lib/raster/color_read.c?rev=68564#L55)
I thought about this. I think there are sufficient quantitative variables
that are integers (just imagine a DEM with 1m vertical precision) to make
this assumption (CELL = categorical) a bit dangerous.
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3043#comment:13>
GRASS GIS <https://grass.osgeo.org>
More information about the grass-dev
mailing list