[GRASS-dev] Re: GRASS 7 status overview

[Michael Barton]

Markus,

This WIKI page is very very helpful (http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures). There are a lot of enhancements to talk about.

I did a quick look at all the new modules and offer the following comments:

Should r.statistics simply be replaced with r.statistics2? No explanation of difference, for example, between kurtosis and kurtosis2. 
It seems that r.statistics3 should be renamed to something more descriptive as it differs functionally from r.statistics

r.external.out and r.colors.out do not generate the GUI when run from the command line. r.colors.out generates a segmentation fault if run without arguments.

Running v.krige generates the following message:  Loading packages, please wait...
Rpy2 not found. Please install it and re-run. 

I thought this was not a *requirement* and that v.krige would run but that some methods simply would not be available. If it is a requirement, shouldn't we make Rpy2 a dependency?

There is a typo in the description for i.emissivity. It should be "sparse" not "spares"

The new image processing look very cool. It looks like some of them should be packaged together under a single menu header (like r.li). Which should be packaged together? 

Some of the new modules relate to solar radiance. Should any of them go under the 'solar radiance and shadows' section in raster? (i.sunhours? i.albedo?). If so, should any be renamed from i.* to r.* for consistency? (or should r.sun and r.sunmask be renamed to i.sun and i.sunmask?)

i.vi: should the user be able to choose which kind of vegetation index is created? Or does the module just create them all?

Trying to run ximgview generates the following error: ERROR: Incompatible library version for module. You need to rebuild GRASS
      or untangle multiple installations.


Michael



On Feb 12, 2010, at 2:26 PM, Markus Neteler wrote:

> On Fri, Feb 12, 2010 at 7:35 AM, Glynn Clements
> <glynn at gclements.plus.com> wrote:
>> Michael Barton wrote:
>> 
>>> Anyway, is there a place that gives an overview of the underlying
>>> changes or plans for GRASS 7 that I should mention?
>> 
>> I don't think so.
> 
> @Glynn: because it should not be done or there isn't?
> 
> An overview page I have compiled here:
> http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures
> 
> It is yet incomplete unfortunately.
> 
>>> Are there some
>>> things that either of you have been doing that you could summarize the
>>> highlights for me to mention? Is the plan still to reorganize the raster
>>> file hierarchy to something more along the lines of the vector
>>> hierarchy? Anything else?
>> 
>> Apart from the display changes, most of it falls under the heading of
>> "clean-up"; even if some of it has been quite radical, e.g. splitting
>> off the raster functions from lib/gis to lib/raster, ditching curses
>> support, etc.
> 
> (see above trac page)
> 
>> For any substantial raster changes, the main issue is how to support
>> legacy formats. IMHO, the ideal solution would be to implement the
>> core GRASS raster I/O "natively" in GDAL (meaning: not depending upon
>> GRASS libraries), so that they can be accessed using r.external[.out].
>> GRASS itself would then only need to understand the new format.
> 
> This would be a great idea, also to get rid of 50% of the GRASS-GDAL
> plugin issues.
> 
> - Plans: implement more openMP support for multi-core CPUs.
> - http://grass.osgeo.org/wiki/GRASS_7_ideas_collection
> 
> Some stuff I have presented here:
> http://www.slideshare.net/markusN/25-years-of-grass-gis-3005600
> 
> Feel free to recylce material (there is a ODP download link somewhere
> on that page).
> 
> Markus