[GRASS-dev] r.li (landscape indices)

Hamish hamish_nospam at yahoo.com
Mon Jan 29 18:45:44 EST 2007


serena wrote:
> If there aren't problems I'll change r.li names.

FYI, the longest historic* names we have are 15-17 chars long:
 d.font.freetype
 r.resamp.interp
 r.terraflow.short
 v.build.polylines


I think it is a mistake to shorten to the point where the module name
doesn't make any sense. ie a natural shortening of a word or an acronym
is ok, but leaving out vowels is bad, and mixed word+acronyms are
confusing. Also we should avoid suffixes like -ing, -s, -ion.


> so:
[including Serena's updates]

> r.li.contrastWeightedEdgeDensity	will be	r.li.cwed
> r.li.dominance          will be          r.li.dominance

nice

> r.li.edgedensity        will be          r.li.edgedens

IMO r.li.edgedensity is preferable (16 chars).

> r.li.meanPatchSize          will be          r.li.meanps
> r.li.meanPixelAttribute     will be          r.li.meanpa

similar enough to be confusing?
what about r.li.patchsize  or r.li.mps  ??

I don't have very good ideas about the other one:
  r.li.pixelatt  ??   r.li.meanpixatt  ?? r.li.mpa  ??
  (of those I prefer r.li.mpa, ....)

> r.li.patchAreaDistributionCV          will be       r.li.padcv
> r.li.patchAreaDistributionRANGE       will be       r.li.padrange
> r.li.patchAreaDistributionSD          will be       r.li.padsd

nice

> r.li.patchdensity           will be          r.li.patchdens

IMO r.li.patchdensity is preferable (17 chars).

> r.li.patchnumber      will be          r.li.patchnum
> r.li.richness         will be          r.li.richness
> r.li.shannon          will be          r.li.shannon
> r.li.shape            will be          r.li.shape
> r.li.simpson          will be          r.li.simpson

nice.

> also, because of the structure of r.li, I think is not a good idea to
> lump different modules.

ok.



[*] "The longest historic names we have are 15-17 chars long"

These new modules are longer (21,18,15):
 v.lidar.edgedetection
 v.lidar.growing
 v.lidar.correction

suggestion:

v.lidar.edgedetection -> v.lidar.edgedetect or v.lidar.edge ?
 (it is a shame to change as "edgedetection" explains the module well)

v.lidar.growing -> v.lidar.classify
 (I think "region growing" is misleading & conflicts with GRASS's common
  use of "region" for raster bounds/resolution; -ing is bad grammar)

v.lidar.correction -> v.lidar.filter


2c,
Hamish




More information about the grass-dev mailing list