Hamish wrote: > > ps- if anyone at the sprint is looking for a nice task, building > > a wxPy color wizard around the ColorBrewer tables might be fun: > > http://colorbrewer2.org/ > > I've got their data reduced to some csv text files from a past > > attempt, and AFAIR the licensing on those was compatible w/ GPL.
(you can also download the excel spreadsheet from their site directly) Helena wrote: > Hamish, if there is no time or interest to do this at the > sprint (fixing the bugs for GRASS6.4.3 release are probably > higher priority) fwiw one of my strong wishes for 6.4.3 is to convert the wxPsMap eps symbols into proper grass symbols and use the 'symbol' command with them. I don't really want to release the current way and have to keep support for the duplicated eps decorations forever. > maybe you can add it into the cartography enhancements topic > for GSoC2013 > http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2013. that's fine too. a minor note about one of the suggestions already there: Google only accepts projects which are primarily coding in nature to SoC. So graphics design, website overhaul, and documentation projects while very important and often badly needed for FOSS projects are actually beyond the scope of the program. IIUC Google's Code In for high school students allows those sorts of things as challenges though. (at perhaps the cost of more mentoring time needed) > Given the max. number of classes supported - 12 and less for > some color schemes, supposedly you cannot distinguish more, I haven't read the academic paper behind the site (I assume there is one based on how they got their funding), so I'm not sure if the colors were selected algorithmically, by educated eye, or a mix of both. If there's a formula we could tap into (like r.watershed has), then all the better for it. > it would be nice to add a button for generating discrete > colors for continuous data, such as elevation, > for a given number of classes - it can be done now, but as > far as I know you would have to reclass your raster first. Even though it is very popular in other widely used software, I've always tried to steer away from applying discrete classes to continuous raster data. IMO it deserves it's own chapter in "How to lie with statistics"*, as it is very easy to fool both yourself and others about what the data says based on the ultimately arbitrary choice (as far as nature is concerned) of intervals. I realize that it is also difficult for the human eye to follow a constant hue and isolines can be useful, so typically what I try to do for those as a compromise is have the continuous gradient colors in the back ground with contour lines of the same data over the top. [*] actually I think there's already a book on it called "How to lie with maps" If you really want to do it though there's no reason to reclass, see the r.colors.stddev script for an example. Just make two rules at the same value right next to each other. e.g., from r.colors.stddev: r.colors "$GIS_OPT_INPUT" color=rules << EOF 0% black $MEAN_MINUS_3STDEV black $MEAN_MINUS_3STDEV red $MEAN_MINUS_2STDEV red $MEAN_MINUS_2STDEV yellow $MEAN_MINUS_1STDEV yellow $MEAN_MINUS_1STDEV green $MEAN_PLUS_1STDEV green $MEAN_PLUS_1STDEV yellow $MEAN_PLUS_2STDEV yellow $MEAN_PLUS_2STDEV red $MEAN_PLUS_3STDEV red $MEAN_PLUS_3STDEV black 100% black EOF screenshots here, but google's pages site seems to have gone a bit haywire: https://sites.google.com/site/hamishbowman/grass_color_maps regards, Hamish _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
