[GRASS-dev] [GRASS GIS] #2024: r.li.setup generates incomplete r.li conf file

[GRASS GIS]

#2024: r.li.setup generates incomplete r.li conf file
------------------------+---------------------------------------------------
 Reporter:  matmar      |       Owner:  rashadkm           
     Type:  defect      |      Status:  assigned           
 Priority:  normal      |   Milestone:  6.4.4              
Component:  Raster      |     Version:  svn-releasebranch64
 Keywords:  r.li.setup  |    Platform:  Linux              
      Cpu:  x86-64      |  
------------------------+---------------------------------------------------

Comment(by hamish):

 Hi,

 I'd like to settle on a common naming scheme for the sample unit raster
 mask maps which r.li.setup produces.

 any comments on:
   rli_sample.<config_file>_<type>[_<cat>]


 I had used the sampled raster name, but maybe the config file is less
 likely to have a name-space conflict. (as config files seem locked to a
 single sampled raster).  The G7 wx version already uses the config file in
 the name.

 ?



 Markus:
 > Yes, that would be very important. Imagine to manually cycle
 > through a vector layer with 1000 polygons, then you have to
 > insert 1000 filenames manually which could simply be the category
 > plus unique number.

 It would be pretty easy to add an "auto" button to the "is this area ok?
 [y/n]" dialog to accept the rest as ok, if that is a reasonable thing that
 makes sense for the analysis methodology.

 So far I just added a warning if there were more than 30 areas to
 consider. Once the d.menu garbage from X-buffer bug is fixed I'd put an
 on-screen "this looks like it will take a very long time, are you sure?"
 chance to abort.

 I notice with NC08's zipcodes_wake and landuse96_28m that many areas are
 outside of the raster-to-analyze's bounding box. Is it ok to add a
 'v.select op=overlap' step to only consider vector areas with data in
 them? How to deal with areas which are half in out-of-bbox null-space?
 Crop them (v.overlay instead of v.select) or leave them to be handled in
 the same way that a null hole in the middle of the raster would be?


 Hamish

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/2024#comment:29>
GRASS GIS <http://grass.osgeo.org>