[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:  assigned   
  Priority:  minor        |   Milestone:  6.4.0      
 Component:  default      |     Version:  unspecified
Resolution:               |    Keywords:             
--------------------------+-------------------------------------------------
Comment (by hamish):

 Glynn:
 > What it probably *should* do is to create a map whose size is
 > based upon the input data, rather than using the current region.
 ..
 > On a related note, r.in.xyz should probably have some way to
 > explicitly specify the bounds and resolution of the created map,
 > either separate n=/s=/e=/w=/res= options and/or a region= option
 > to use a named region.

 I hear your point re. standardizing r.in.* modules, but r.in.xyz is not
 like other import modules and I do not think it should work that way. It
 is as much a binning filter as a data importer; the XYZ data is not a
 finished product to be loaded into the GIS without data loss. The module
 is by design a data aggregator, ie lossy. It is not loading the data raw &
 intact, it is processing it into something new.

 here are some screenshots of a recent use:
  http://bambi.otago.ac.nz/hamish/grass/r.in.xyz/saunders_track.jpg
  http://bambi.otago.ac.nz/hamish/grass/r.in.xyz/saunders_bathy.png
  (with thanks to Bob Covill for the idea)

 XYZ from the ship's combined NMEA lat/lon+depth sounder is processed for
 an area of interest. In the image with the chart you can see the ship's
 track (red) continues away many miles from the survey site back to port.
 Loading in at rough resolution then using d.zoom to interactively set the
 bounds is way easier than trying to use d.where + manually set 'n= s= w=
 e='. And 'res=' is another thing altogether, but being able to use
 'g.region res= -a' really helps in a way which would be a pain to
 calculate manually.

 With a LIDAR study with 40GB of raw x,y,z ASCII results is probably more
 important to not try and load the entire spatial coverage in at once.

 So I would argue that not using the full spatial extent of the XYZ data is
 the typical mode of operation for this module, and using d.zoom &
 'g.region res= -a' after getting the rough coordinates with 'r.in.xyz -s'
 and then doing a rough first pass is the recommended workflow.


 In summary, it's a data aggregator not just a data importer and I'm
 leaning to "won't fix".


 Hamish

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