[GRASS-dev] [GRASS GIS] #3157: support for "offset" and "num_digits" in r.import

[GRASS GIS]

#3157: support for "offset" and "num_digits" in r.import
--------------------------+-------------------------
  Reporter:  veroandreo   |      Owner:  grass-dev@…
      Type:  enhancement  |     Status:  new
  Priority:  normal       |  Milestone:  7.2.0
 Component:  Raster       |    Version:  svn-trunk
Resolution:               |   Keywords:  r.import
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+-------------------------

Comment (by mmetz):

 Replying to [ticket:3157 veroandreo]:
 > It would be nice to have the options "offset" and "num_digits" from
 G7:r.in.gdal also in G7:r.import. These options make it easier to work
 with multiband maps, as those provided for example in ECAD dataset, given
 that the zero padding in the imported map names allows then for ordered
 listing of resulting maps.

 The purpose of the [r|v].import modules is to provide a simplified
 interface for easy import of spatial data, combining r.in.gdal + r.proj
 and v.in.ogr + v.proj. That means a reduced number of options to keep the
 interface simple and some checks if the data can indeed be reprojected if
 need be.

 Despite the existence of [r|v].import, it is always safer to use r.in.gdal
 + r.proj and v.in.ogr + v.proj separately because [r|v].import do not
 catch all problems that can occur when 1) importing data, 2) reprojecting
 data.

 Therefore I propose to have a nice GUI interface for r.import/v.import
 similar to the current GUI interface for r.in.gdal/v.in.ogr. At the very
 least, the selection of the input type (file, directory, database,
 protocol) should be available. The default GUI interface for
 r.in.gdal/v.in.ogr can then be again what you get with e.g. r.in.gdal
 --ui. We would then have a relatively simple and comfortable method +
 interface for importing "easy" data provided by [r|v].import and the full
 options, also in the GUI interface of r.in.gdal/v.in.ogr for the not-so-
 easy data to be imported.

 IOW, [r|v].import should IMHO provide a simple (simplified) interface to
 easily import data with reprojection on-the-fly. If [r|v].import fails, or
 if you want more control over the import process, you should have access
 to all the options of r.in.gdal/v.in.ogr also through the GUI.

 BTW, the default answers of r.import for extent=input and
 resolution=estimated seem dangerous to me.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3157#comment:1>
GRASS GIS <https://grass.osgeo.org>