#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 |
-------------------------+--------------------------------------------------
While v.in.ogr offers "-r Limit import to the current region"
the module r.in.gdal does not.
The code for such a -r flag will be like
{{{
gdal_translate
-projwin ulx uly lrx lry:
Selects a subwindow from the source image for
copying (like -srcwin) but with the corners given
in georeferenced coordinates.
}}}
#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 [ticket:2055 neteler]:
> While v.in.ogr offers "-r Limit import to the current region"
> the module r.in.gdal does not.
>
v.in.ogr -r imports all features that overlap with the current region. The
result might thus have extents extending beyond the current region, which
makes sense.
Translated to raster import, I see a disadvantage when limiting the import
to the current region: for a given project, raw data are commonly coming
from different sources with different extents and resolution. You would
then need to use one of the r.resamp.* modules to resampling raw data to
the current region, and r.resamp.* modules typically extend the current
region by the margin required for resampling (if not nn). Limiting the
import to the current region followed by resampling would thus eat away
rows and columns at the region's borders.
#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 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.
>
> What would be the advantage of r.in.gdal -r?
That would exactly be my use case. Example: I need a tiny area from the
huge
Black Marble map or the gmted2010 DEM (files in GB range). Getting it in
at
original resolution but cut to my area would be very useful as optional
flag.
#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: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.
> >
> > What would be the advantage of r.in.gdal -r?
>
> That would exactly be my use case. Example: I need a tiny area from the
huge
> Black Marble map or the gmted2010 DEM (files in GB range). Getting it in
at
> original resolution but cut to my area would be very useful as optional
flag.
Why would it be useful, even though it would introduce resampling
artefacts? Why not use r.external?
#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:1 mmetz]:
>
> Limiting the import to the current region followed by resampling would
thus eat away rows and columns at the region's borders.
To be precise: inside the current region, effectively shrinking the
current region.
#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 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.
> > > What would be the advantage of r.in.gdal -r?
> >
> > That would exactly be my use case. Example: I need a tiny area from
the huge
> > Black Marble map or the gmted2010 DEM (files in GB range). Getting it
in at
> > original resolution but cut to my area would be very useful as
optional flag.
>
> Why would it be useful, even though it would introduce resampling
artefacts?
Artifacts I would only expect at the border cells in the worst case and
they
could be imported even completely (these pixels) leading to a tiny
extension
to the current region.
> Why not use r.external?
wxNIZ and other modules failed. 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).
#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?
#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 veroandreo):
Adding a use case here to support the addition of -r flag to r.in.gdal
I'm working with time series (2003-2013) of MODIS-Aqua L3 Chlorophyll
concentration and Rrs data. Data is available globally
(http://oceandata.sci.gsfc.nasa.gov/MODISA/Mapped/8Day/4km/chlor/), but I
just need a small sample covering the argentinean sea. I have more than 40
images per year, 10 years of data, 5 different products, ~150 Mb each.
That's a lot of space for my notebook. I cannot loop over all data set cos
i fill the disk completely... So, i have to go folder by folder
uncompressing (original data are .bz2 hdf files), importing into grass,
subseting, and then removing the global files...
I could really use a flag to subset to the region extent on-the-fly when
importing into grass and save disk space and time
#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:8 veroandreo]:
> Adding a use case here to support the addition of -r flag to r.in.gdal
>
> I'm working with time series (2003-2013) of MODIS-Aqua L3 Chlorophyll
concentration and Rrs data. Data is available globally
(http://oceandata.sci.gsfc.nasa.gov/MODISA/Mapped/8Day/4km/chlor/), but I
just need a small sample covering the argentinean sea. I have more than 40
images per year, 10 years of data, 5 different products, ~150 Mb each.
That's a lot of space for my notebook. I cannot loop over all data set cos
i fill the disk completely... So, i have to go folder by folder
uncompressing (original data are .bz2 hdf files), importing into grass,
subseting, and then removing the global files...
>
> I could really use a flag to subset to the region extent on-the-fly when
importing into grass and save disk space and time
Why not use r.external? This requires very little disk space. If you want
to clip the import to the current region and delete the external raster
data afterwards, you could use
#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 veroandreo):
Thanks, Markus! I wasn't aware of r.external. That solved the disk space
issue, but it is not as straightforward as a -r flag in r.in.gdal would be
Best,
Vero
