Hello list, I have a problem with exporting a DEM to *tif. In a first step I import it via r.in.gdal and in a second step I export it with r.out.gdal and the file is not the same anymore. GDAL reduce the file to one pixel but a greater storage size… Even the settings (tags) changes total. Here are some extracts from gdalinfo: Before: Driver: GTiff/GeoTIFF Size is 108, 84 Coordinate System is: PROJCS[“WGS 84 / UTM zone 45N”, […] Band 1 Block=64x64 Type=UInt16, ColorInterp=Gray Computed Min/Max=4349.000,5738.000 [EOF] After: Driver: GTiff/GeoTIFF Size is 1, 1 Coordinate System is: PROJCS[“WGS 84 / UTM zone 45N”, […] Band 1 Block=1x1 Type=UInt16, ColorInterp=Palette Computed Min/Max=0.000,0.000 NoData Value=-32768 Metadata: COLOR_TABLE_RULES_COUNT=1 COLOR_TABLE_RULE_RGB_0=4.349000e+03 5.738000e+03 0 0 0 255 255 255 Color Table (RGB with 65536 entries) 0: 0,0,0,255 1: 0,0,0,255 [and 65533 more lines …] I mean it is a very simple process (import/export) but it don’t work on my computer satisfactorily. So what I’m doing wrong? Kind regards, Stefan |
|---|
On 14/01/09 16:49, Stefan Mietke wrote:
Hello list,
I have a problem with exporting a DEM to *tif.
There's been quite a lot of discussion on the lists concerning r.out.gdal to GeoTiffs. See for example [1],[2] and the long thread in the relevant track ticket[3]. Several of the issues (notably the color table) have been addressed by recent changes which should be in the 6.4 release candidate. So you might want to try with that.
In a first step I import it via r.in.gdal and in a second step I export it with r.out.gdal and the file is not the same anymore. GDAL reduce the file to one pixel but a greater storage size..
As mentioned in [1], block size only seems to be relevant for tiles. What exactly is the problem ? I mean, except for the fact that the files are not identical, what is going wrong for you ?
Moritz
[1] http://thread.gmane.org/gmane.comp.gis.gdal.devel/16395
[2] http://thread.gmane.org/gmane.comp.gis.grass.user/25084
[3] http://trac.osgeo.org/grass/ticket/73
Thank you, for your quik response. The problem is, that the data is unusable after importing/exporting them … There is only 1 pixel left of the original DEM and all elevation data are missing! |
|---|
Now with a new friend-happy design! Try the new Yahoo! Canada Messenger
Stefan Mietke wrote:
Hello list,
I have a problem with exporting a DEM to *tif.
In a first step I import it via r.in.gdal and in a second step I export it with r.out.gdal and the file is not the same anymore. GDAL reduce the file to one pixel but a greater storage size..
Even the settings (tags) changes total.
Here are some extracts from gdalinfo:
Before:
Driver: GTiff/GeoTIFF
Size is 108, 84
Coordinate System is:
PROJCS["WGS 84 / UTM zone 45N",
[...]Band 1 Block=64x64 Type=UInt16, ColorInterp=Gray
Computed Min/Max=4349.000,5738.000
[EOF]After:
Driver: GTiff/GeoTIFF
Size is 1, 1
r.out.gdal works within the current region settings, i.e. your exported raster may have different extends and a different resolution.
Your region settings are wrong.
Check with g.region -p
You will see that your region is set to have only one row and only one column
run g.region rast=myrast
well, not exactly, replace myrast with the name of the raster you want to export
then run r.out.gdal, you should see that the files are identical.
Coordinate System is:
PROJCS["WGS 84 / UTM zone 45N",
[...]Band 1 Block=1x1 Type=UInt16, ColorInterp=Palette
Computed Min/Max=0.000,0.000
NoData Value=-32768
Metadata:
COLOR_TABLE_RULES_COUNT=1
COLOR_TABLE_RULE_RGB_0=4.349000e+03 5.738000e+03 0 0 0 255 255 255
Color Table (RGB with 65536 entries)
0: 0,0,0,255
1: 0,0,0,255[and 65533 more lines ...]
run r.out.gdal -c
the -c flag supresses exporting of these long colortables, they cause problems.
Hope that helps,
Markus M
PS: please post messages as plain text
I mean it is a very simple process (import/export) but it don't work on my computer satisfactorily. So what I'm doing wrong?
Kind regards,
Stefan
------------------------------------------------------------------------
*Yahoo! Canada Toolbar :* Search from anywhere on the web and bookmark your favourite sites. Download it now! <http://ca.toolbar.yahoo.com/>
------------------------------------------------------------------------
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Dear Grass user,
In order to use a cellular automata model to simulate a landscape
evolution I should use (because the code require it) a DEM where the
main water flow goes from left to right. I want to use this code to
simulate an area where the water comes from north to south so I have to
rotate the DEM of 90 degrees.
Does anyone know how can I do it?
I found on web this project
http://www.thedigitalmap.com/~carlos/dm4dem_en.html
that seems do it...
did anyone use it before? If yes could you explain me how to install it?
I didn't find...
Thanks
Pierluigi
pierluigi de rosa wrote:
In order to use a cellular automata model to simulate a landscape
evolution I should use (because the code require it) a DEM where the
main water flow goes from left to right. I want to use this code to
simulate an area where the water comes from north to south so I have to
rotate the DEM of 90 degrees.
Does anyone know how can I do it?
No way I know of within GRASS, but it is quite easy if you export the map
to Matlab (or GNU Octave) and then reimport the result to GRASS.
GRASS: r.out.mat, r.in.mat
Matlab/Octave:
map_data = map_data'; % (transpose)
% and also change map n,s,e,w bounds as needed before resaving .mat file
probably a similarly simple task if you use the R-statistics/GRASS
integration.
Hamish
> so I have to rotate the DEM of 90 degrees.
Hamish:
No way I know of within GRASS, but it is quite easy if you export the map
to Matlab (or GNU Octave) and then reimport the result to GRASS.GRASS: r.out.mat, r.in.mat
Matlab/Octave:
>> map_data = map_data'; % (transpose)
or perhaps: (90 vs 270 rotation; see also flipud())
map_data = fliplr(map_data');
>> % and also change map n,s,e,w bounds as needed before resaving .mat
Hamish