[GRASS-dev] Re: [GRASS GIS] #37: r.in.xyz increase region based on input data

[GRASS GIS]

#37: r.in.xyz increase region based on input data
--------------------------+-------------------------------------------------
  Reporter:  marisn       |       Owner:  hamish     
      Type:  enhancement  |      Status:  reopened   
  Priority:  minor        |   Milestone:  6.4.0      
 Component:  default      |     Version:  unspecified
Resolution:               |    Keywords:             
--------------------------+-------------------------------------------------
Comment (by hamish):

 I will write a demonstration r.in.xyz.auto script providing the desired
 functionality wrt bounds so we can test how other methods could work.

 However, for this module picking your resolution (thus average number of
 input points per cell bin) is *absolutely fundamental* to results and must
 be chosen with care and supervision. This probably means a few trial
 'r.in.xyz method=n' + 'r.univar n_map' steps to get it right. This is
 unknowable information from the data which must be supplied by the user,
 and the workflow is multi-step.


 Solutions:
  * We could use the current region resolution with bounds taken from
 scanning step. In this case the user is 90% likely not to have considered
 the resolution first and will get bad results or a out-of-memory error as
 the resolution will be badly wrong. Also it means using a g.region step
 first anyway, so we're not really that much better off.

  * We could add a res= option for use with an optional auto-bounds setting
 flag. I'm not very excited about adding new options and flags, but it's a
 possibility. 'g.region -a' like code would need into the module and offset
 region would be impossible (s=25 n=75 res=50).

  * We could choose a default resolution that made the output like a
 1000x1000 map. Lame.


 I think that all these solution are to some extent poor and would be
 little more consistent with other r.in.* modules than the current way. In
 any case import from auto-scanned bounds should not be changed to be the
 default, and custom subregion and resolution must remain possible. In
 practice I have found that a cropping step is generally wanted, so it is
 useful to combine it with this first import step.

 Re consistency we just have to note that the module works on the current
 region like other r. modules and not like other r.in. modules.


 I would also note that this is all well discussed in the man page, with an
 example.


 still unconvinced,
 Hamish

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/37#comment:10>
GRASS GIS <http://grass.osgeo.org>
GRASS Geographic Information System (GRASS GIS) - http://grass.osgeo.org/