[GRASS-dev] [GRASS GIS] #2055: r.in.gdal lacks flag "-r Limit import to the current region"

[GRASS GIS]

#2055: r.in.gdal lacks flag "-r Limit import to the current region"
-------------------------+--------------------------------------------------
 Reporter:  neteler      |       Owner:  grass-dev@…              
     Type:  enhancement  |      Status:  new                      
 Priority:  normal       |   Milestone:  7.0.0                    
Component:  Raster       |     Version:  svn-trunk                
 Keywords:  r.in.gdal    |    Platform:  Unspecified              
      Cpu:  Unspecified  |  
-------------------------+--------------------------------------------------

Comment(by mmetz):

 Replying to [comment:5 neteler]:
 > Replying to [comment:3 mmetz]:
 > > Replying to [comment:2 neteler]:
 > > > Replying to [comment:1 mmetz]:
 > > > ...
 > > > > Limiting the import to the current region followed by resampling
 would thus eat away rows and columns at the region's borders.
 >
 > I don't understand why resampling is involved. Keep pixels as-is within
 the
 > "MASK", i.e. current region, if -r is used.

 I meant, if resampling is one of the following processing steps, it will
 produce artefacts, because r.resamp.* modules typically extend the current
 region by the margin required for resampling (if not nn).

 >
 > > Why not use r.external?
 >
 > wxNIZ and other modules failed.

 Sounds like a need for separate tickets for wxNVIZ and those other
 modules.

 > Secondly there is always the risk that the
 > original is deleted. Finally, why keep a big file when I only need to
 use
 > a tiny fraction of it in GRASS... (think disk space on laptops).

 So the potential advantage would be disk space? Why not use r.in.gdal +
 r.resamp.* + g.remove?

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2055#comment:6>
GRASS GIS <http://grass.osgeo.org>