Hi,
Thanks to those who helped with my previous query- I'm now getting somewhere!
Next I'm trying to bring in some SRTM topographic data. I've used MacDEM to merge 4 degree squares and exported these as a tiff with world file. Using r.in.tiff, I get three bands (.r, .g, .b). However band .r displays as null values, .g and .b display as greyscale.
Any ideas what's going on?
Thanks,
Lawrence
Probably because MacDEM saves a color TIFF - I think the defaults have a blueish color for either the zero elevs or nulls. (it's been a while since I used MacDEM) Even if you could get it to save a grayscale tiff, you'd still have to deal with the nulls somehow.
A better way to bring in SRTMs into GRASS is directly, using r.in.gdal. Then use GRASS to patch them together. There's been a few queries about it on the list recently - check the archives. Maybe when I have time to figure out the new wiki I'll add something there.
On Nov 11, 2004, at 4:25 AM, lawrence moran wrote:
Hi,
Thanks to those who helped with my previous query- I'm now getting somewhere!
Next I'm trying to bring in some SRTM topographic data. I've used MacDEM to merge 4 degree squares and exported these as a tiff with world file. Using r.in.tiff, I get three bands (.r, .g, .b). However band .r displays as null values, .g and .b display as greyscale.
Any ideas what's going on?
Thanks,
Lawrence
-----
William Kyngesburye <williamk@mappingspecialists.com>
Mapping Specialists <http://www.mappingspecialists.com>
Don't Panic
> Next I'm trying to bring in some SRTM topographic data. I've used
> MacDEM to merge 4 degree squares and exported these as a tiff with
> world file. Using r.in.tiff, I get three bands (.r, .g, .b). However
> band .r displays as null values, .g and .b display as greyscale.A better way to bring in SRTMs into GRASS is directly, using r.in.gdal.
Then use GRASS to patch them together. There's been a few queries
about it on the list recently - check the archives. Maybe when I have
time to figure out the new wiki I'll add something there.
Try Markus's r.in.srtm scripts, they work quite well.
http://mpa.itc.it/rs/srtm/index.html
Then patch together with r.patch.
Hamish
Seems a bit messy, going thru tiff, then fixing INT16 problems. I prefer to go direct from the SRTM file.
I've been using my own clunky method for generating the hdr file, but Markus' would work if you just remove the gdal_translate step in srtm_generate_hdr.sh. Then just use r.in.gdal. It correctly takes care of the BIL cell center -> GRASS cell corner translation (you get a raster who's bounds are 1.5 seconds outside the degree square). You could simplify it all by merging the generate hdr into r.in.srtm.
On Nov 11, 2004, at 4:13 PM, Hamish wrote:
Next I'm trying to bring in some SRTM topographic data. I've used
MacDEM to merge 4 degree squares and exported these as a tiff with
world file. Using r.in.tiff, I get three bands (.r, .g, .b). However
band .r displays as null values, .g and .b display as greyscale.A better way to bring in SRTMs into GRASS is directly, using r.in.gdal.
Then use GRASS to patch them together. There's been a few queries
about it on the list recently - check the archives. Maybe when I have
time to figure out the new wiki I'll add something there.Try Markus's r.in.srtm scripts, they work quite well.
http://mpa.itc.it/rs/srtm/index.html
Then patch together with r.patch.
Hamish
-----
William Kyngesburye <kyngchaos@charter.net>
http://webpages.charter.net/kyngchaos/
Earth: "Mostly harmless"
- revised entry in the HitchHiker's Guide to the Galaxy
On Thu, Nov 11, 2004 at 10:27:55AM -0600, William K wrote:
A better way to bring in SRTMs into GRASS is directly, using r.in.gdal.
Then use GRASS to patch them together. There's been a few queries
about it on the list recently - check the archives. Maybe when I have
time to figure out the new wiki I'll add something there.
Here you can grab the scripts:
http://mpa.itc.it/rs/srtm/index.html
Markus
On Thu, Nov 11, 2004 at 06:05:00PM -0600, William K wrote:
Seems a bit messy, going thru tiff, then fixing INT16 problems. I
prefer to go direct from the SRTM file.I've been using my own clunky method for generating the hdr file, but
Markus' would work if you just remove the gdal_translate step in
srtm_generate_hdr.sh. Then just use r.in.gdal. It correctly takes
care of the BIL cell center -> GRASS cell corner translation (you get a
raster who's bounds are 1.5 seconds outside the degree square). You
could simplify it all by merging the generate hdr into r.in.srtm.
... yes, and then it should go into 5.7 ...
Please send the merged script if you find the time.
Markus
Lawrence,
I see others have offered more comprehensive solutions. However, this might
help you and others with r.in.tiff.
Based on my experience with the module, r.in.tiff assumes that you have a
RGB color file and tries to parse it into red, green, and blue channels. In
your case, you have a single channel elevation file. Both your green (*.g)
and blue (*.b) bands are probably identical (subtract one from the other
using r.mapcalculator to check). I'm not sure what is going on with the red
channel (*.r). It might or might not be significant.
In other words, I *think* that either of your green or blue channels are
your imported DEM. You can do a few spot checks using d.what.raster to
verify this.
Michael Barton
On 11/11/04 3:25 AM, "lawrence moran" <L.J.Moran@newcastle.ac.uk> wrote:
Hi,
Thanks to those who helped with my previous query- I'm now getting somewhere!
Next I'm trying to bring in some SRTM topographic data. I've used MacDEM to
merge 4 degree squares and exported these as a tiff with world file. Using
r.in.tiff, I get three bands (.r, .g, .b). However band .r displays as null
values, .g and .b display as greyscale.Any ideas what's going on?
Thanks,
Lawrence
____________________
C. Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA
Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>