I have a large ortho image, that is in MrSID format (A full county at high res). The file is ~3.5 gig. It covers a much larger area then I need. So I set my region to the size that I do need, and then imported. The import took something like 10 hrs. And, I now see that in my PERMANENT folder I have 3 files that are each 15 gig (one red, one blue, one green),
The map was imported, but if I zoom to the size of the current map, it seems that the whole map was imported, not just the area inside the current region.
I thought that imports are cropped to the current region? Am I mistaken about this? Is there some setting to cause this to happen?
I did the import with r.in.gdal. I am using the binary release of 6.4 on a Mac.
The reasons that I care are 1) This map, for a small area of interest, it taking up 45 gig on my hard drive. 2) Because the map is so large, it takes a while for the display to update when I make any changes.
On 20/09/2010 18:09, Adam Dershowitz, Ph.D., P.E. wrote:
I have a large ortho image, that is in MrSID format (A full county at high res). The file is ~3.5 gig. It covers a much larger area then I need. So I set my region to the size that I do need, and then imported. The import took something like 10 hrs. And, I now see that in my PERMANENT folder I have 3 files that are each 15 gig (one red, one blue, one green),
The map was imported, but if I zoom to the size of the current map, it seems that the whole map was imported, not just the area inside the current region.
I thought that imports are cropped to the current region? Am I mistaken about this? Is there some setting to cause this to happen?
I did the import with r.in.gdal. I am using the binary release of 6.4 on a Mac.
The reasons that I care are 1) This map, for a small area of interest, it taking up 45 gig on my hard drive. 2) Because the map is so large, it takes a while for the display to update when I make any changes.
Any guidance?
> Raster import and export
>
> The module r.in.gdal offers a common interface for...
> The full map is always imported.
On 20/09/2010 18:09, Adam Dershowitz, Ph.D., P.E. wrote:
I have a large ortho image, that is in MrSID format (A full county at high res). The file is ~3.5 gig. It covers a much larger area then I need. So I set my region to the size that I do need, and then imported. The import took something like 10 hrs. And, I now see that in my PERMANENT folder I have 3 files that are each 15 gig (one red, one blue, one green),
The map was imported, but if I zoom to the size of the current map, it seems that the whole map was imported, not just the area inside the current region.
I thought that imports are cropped to the current region? Am I mistaken about this? Is there some setting to cause this to happen?
I did the import with r.in.gdal. I am using the binary release of 6.4 on a Mac.
The reasons that I care are 1) This map, for a small area of interest, it taking up 45 gig on my hard drive. 2) Because the map is so large, it takes a while for the display to update when I make any changes.
Any guidance?
If you used r.in.gdal, then I guess your gdal has MrSID support. So you should be able to use the gdal_translate utility with the -projwin flag to clip out the area you need, and create a new tif. Something like:
gdal_translate -projwin ulX ulY lrX lrY original.sid clipped.tif
> Raster import and export
>
> The module r.in.gdal offers a common interface for...
> The full map is always imported.
On 20/09/2010 18:09, Adam Dershowitz, Ph.D., P.E. wrote:
I have a large ortho image, that is in MrSID format (A full county at high res). The file is ~3.5 gig. It covers a much larger area then I need. So I set my region to the size that I do need, and then imported. The import took something like 10 hrs. And, I now see that in my PERMANENT folder I have 3 files that are each 15 gig (one red, one blue, one green),
The map was imported, but if I zoom to the size of the current map, it seems that the whole map was imported, not just the area inside the current region.
I thought that imports are cropped to the current region? Am I mistaken about this? Is there some setting to cause this to happen?
I did the import with r.in.gdal. I am using the binary release of 6.4 on a Mac.
The reasons that I care are 1) This map, for a small area of interest, it taking up 45 gig on my hard drive. 2) Because the map is so large, it takes a while for the display to update when I make any changes.
Any guidance?
If you used r.in.gdal, then I guess your gdal has MrSID support. So you should be able to use the gdal_translate utility with the -projwin flag to clip out the area you need, and create a new tif. Something like:
gdal_translate -projwin ulX ulY lrX lrY original.sid clipped.tif
> Raster import and export
>
> The module r.in.gdal offers a common interface for...
> The full map is always imported.
I ended up just using r.composite on the maps that I had imported. That did the crop to the current region that I had expected. Then I deleted the 45 gig of maps that I didn't need, but already had.
The gdal_translate looks like a great solution for next time, before I do the huge import.
I ended up just using r.composite on the maps that I had
imported. That did the crop to the current region that
I had expected. Then I deleted the 45 gig of maps that
I didn't need, but already had.
The gdal_translate looks like a great solution for next
time, before I do the huge import.
to sum up:
* r.in.gdal differs from most raster modules in that it imports
the entire map and ignores the current region.
* gdal_translate can be used to crop out an area of interest
before import with its -projwin or -srcwin options.
* after import any subsequent raster module will respect the
region settings, so in effect crop to the current region. The
most basic example of this is: "r.mapcalc "cropped = imported".
* r.composite is lossy, which is important for analytical tasks
but not for visual use. If analyzing the data keep it in
individual R,G,B bands.
>> to sum up:
>>
>> * r.in.gdal differs from most raster modules in that it
>> imports the entire map and ignores the current region.
Hermann:
By the way: is there a convenient overview of raster
modules that do NOT respect the current region?
no, but the general theme is that raster modules which import
pre-existing datasets (r.in.*) preserve that data arrays; while
modules which create new raster maps (r.* including v.to.rast,
r.in.poly, r.in.xyz, and r.proj) will respect the region.
and then of course there will always be an exception or two to
the rule, but you can pretty much trust the above.
>> By the way: is there a convenient overview of raster modules that do NOT
>> respect the current region?
>
> In general: r.in.* ignore the region, and import rasters
> cell-for-cell. r.resamp.* and r.proj ignore the region for reading but
> honour it for writing.
Thanks for the overview. I guess that r.reclass could also be added into
the first group.
r.reclass doesn't read or write raster data, so the region doesn't
come into it.
Similar issues apply to r.info, r.support, r.compress, r.null,
r.timestamp etc.
The region only matters for modules which read or write raster data.
This includes most (but not all) r.* and i.* modules, as well as some
other modules (e.g. v.what.rast).
>> By the way: is there a convenient overview of
>> raster modules that do NOT respect the current region?
...
I guess that r.reclass could also be added into the first group.
The fundamental and fantastic thing to realize about r.reclass is that is
doesn't actually write a new map, it creates a virtual map based on classes
of the original. It acts as a seamless filter between you and the data.
With a bit of imagination it can be an extraordinarily effective tool,
which after many years of using GRASS I think I'm only beginning to tap.
The fundamental and fantastic thing to realize about r.reclass is that is
doesn't actually write a new map, it creates a virtual map based on classes
of the original. It acts as a seamless filter between you and the data.
With a bit of imagination it can be an extraordinarily effective tool,
which after many years of using GRASS I think I'm only beginning to tap.
I am actually using r.reclass quite frequently in batch processing. I read about the concept that a reclass map is some sort of a lightweigt virtual map, but for simple-minded GRASS users like me, r.reclass is just another map-creating raster module. As the documentation states:
For quite a while, I used to always align the current region settings with the base map before running r.reclass. After some time, I noted that this isn’t necessary, as the generated virtual map is always based on the full extent of the base map and its original resolution. I just couldn’t find this mentioned in the documentation.
For quite a while, I used to always align the current region settings
with the base map before running r.reclass. After some time, I noted
that this isn't necessary, as the generated virtual map is always based
on the full extent of the base map and its original resolution. I just
couldn't find this mentioned in the documentation.
A reclass map is just a reference to the base map and a list of
category mappings. It doesn't have a region of its own; e.g. if you
change the bounds of the base map via r.region, the bounds of the
reclass map will change to match.
Thanks for all the explanations. Now I know better. Below [1], I tried to bring all relevant snippets together. Wouldn't it make sense to add some of these details to g.region.html, or so?
Hermann
[1] Glynn and Hamish gave these helpful explanations:
> to sum up:
>
> * r.in.gdal differs from most raster modules in that it imports
> the entire map and ignores the current region.
>
> * gdal_translate can be used to crop out an area of interest
> before import with its -projwin or -srcwin options.
>
> * after import any subsequent raster module will respect the
> region settings, so in effect crop to the current region. The
> most basic example of this is: "r.mapcalc "cropped = imported".
>
> Hermann:
>> By the way: is there a convenient overview of raster
>> modules that do NOT respect the current region?
>
> no, but the general theme is that raster modules which import
> pre-existing datasets (r.in.*) preserve that data arrays; while
> modules which create new raster maps (r.* including v.to.rast,
> r.in.poly, r.in.xyz, and r.proj) will respect the region.
>
> and then of course there will always be an exception or two to
> the rule, but you can pretty much trust the above.
>
>
> r.reclass doesn't read or write raster data, so the region doesn't
> come into it.
>
> Similar issues apply to r.info, r.support, r.compress, r.null,
> r.timestamp etc.
>
> The region only matters for modules which read or write raster data.
> This includes most (but not all) r.* and i.* modules, as well as some
> other modules (e.g. v.what.rast).
>
> In general: r.in.* ignore the region, and import rasters
> cell-for-cell. r.resamp.* and r.proj ignore the region for reading but
> honour it for writing.
>
>
> A reclass map is just a reference to the base map and a list of
> category mappings. It doesn't have a region of its own; e.g. if you
> change the bounds of the base map via r.region, the bounds of the
> reclass map will change to match.
>