[GRASS-dev] [GRASS-SVN] r62845 - in grass/trunk/scripts: . d.shadedmap r.shadedmap

[Vaclav Petras]

On Fri, Nov 21, 2014 at 4:09 AM, Markus Neteler <neteler at osgeo.org> wrote:

> Hi,
>
> On Fri, Nov 21, 2014 at 5:00 AM,  <svn_grass at osgeo.org> wrote:
> > Author: wenzeslaus
> > Date: 2014-11-20 20:00:29 -0800 (Thu, 20 Nov 2014)
> > New Revision: 62845
> >
> > Added:
> >    grass/trunk/scripts/d.shadedmap/dshadedmap.png
> >    grass/trunk/scripts/r.shadedmap/
> >    grass/trunk/scripts/r.shadedmap/r.shadedmap.html
> >    grass/trunk/scripts/r.shadedmap/r.shadedmap.py
> >    grass/trunk/scripts/r.shadedmap/rshadedmap.png
> > Removed:
> >    grass/trunk/scripts/r.shadedmap/d.shadedmap.html
> >    grass/trunk/scripts/r.shadedmap/d.shadedmap.py
> > Modified:
> >    grass/trunk/scripts/Makefile
> >    grass/trunk/scripts/d.shadedmap/d.shadedmap.html
> >    grass/trunk/scripts/d.shadedmap/d.shadedmap.py
> >    grass/trunk/scripts/r.shadedmap/Makefile
> > Log:
> > d.shadedmap: split into two modules d.shadedmap for display and
> r.shadedmap for creating raster
> >
> >  * the raster creation functionality was anyway not sharing any code
> with the display part in the original d.shadedmap
> >  * similar things are parameters and manual, so there is now some
> duplication in this
> >  * thanks to r.shadedmap, GRASS shading is available to QGIS and others
> >  * in wxGUI one can create the raster in usual way (before: pressing OK
> or Apply in d command dialog with no overwrite support)
> >  * adds also brighten functionality for r.shadedmap implemented
> according to r.his manual (probably not perfect)
> >  * changing examples to NC and adding images (different image for each
> module)
>
> Thanks for your efforts, Vaclav.
>
> But honestly I am not convinced to introduce yet another script
> "r.shadedmap" which may add confusion.
> At time we have
>
> - d.his
> - d.rgb
> - d.shadedmap
> - r.his
> - r.rgb
> - r.blend
> - r.shaded.relief
>
> new
> - r.shadedmap
>
> I see confusion between r.blend and r.shadedmap:
>
> r.blend: Blends color components of two raster maps by a given ratio.
> r.shadedmap: Drapes a color raster over an shaded relief or aspect map.
>
> and would suggest to merge both into one script.
>
> I don't think that it is a good idea. There are another sources of
confusion too. d.shadedmap gives nice picture but cannot create the shade
itself, so you have to find some other module. If you hit r.shaded.relief
first, you might be confused from getting the shade but not the nice
picture. r.shadedmap does not changes this two-step approach but at least
it makes clear how to create shaded map with colors.

It is true that the inputs and outputs of r.shadedmap and r.blend are the
same but what they are doing is different (at least according to my rough
idea about r.blend). Merging would again hide the creating of colorful
shaded map in some other module.

The other reason for splitting d.shadedmap into two was that in code there
were basically two different scripts not sharing any code. r.shadedmap does
not share any code with r.bled and thus there would be still the reason to
split them because I think that no shared code points to the fact that the
functionalities are not related enough to be in one module and you can
better express the difference be keeping them separate.

I'm not saying that the names or descriptions cannot be improved. I just
left them as they are since I had no better idea.

Also I forgot about r.bled when I was committing r.shadedmap, they should
definitively mention each other in see also. Which reminds me about idea of
mentioning differences to given module in see also section.

Also I should mention that r.blend is one of the modules I want to change
from prefix (output_prefix) to explicit options (red, green, blue). Option
to create composite would make sense too.

Just partially related is that i.rgb.his and its sister module i.his.rgb
are using input and output in their options (red_input, green_input, ...,
hue_output, ..., hue_input, ...). This might be actually helpful with
understanding what are inputs and what outputs but I actually think that it
would be better to remove the _input and _output parts from the option
names for consistency with the other modules and also to make them shorter.
What is input and what is output should be clear from the name of the
module and description of the options. The current long names are not much
used anyway and some of the possible shortened form si used instead I'm
afraid.

I hope you will agree at least with part of this,
Vaclav


> thanks
> Markus
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20141121/c1193251/attachment.html>