Daniel Farnan @ San Francisco wrote:
Worked much faster than 4 days, but generated a blank (white) raster.
- this may be due to the srtm data(?). All were imported as .tif with
r.in.gdal.
Please don't reply in priv when other users might benefit from the
discussion or be able to help you.
What is each raster's min-max (r.info -r)? Is null present?
When you set the region to cover them all (g.region
rast=rast1,rast2,...,rast11 -a), do you see what you expect when you do:
d.mon x0
d.rast one_of_the_rasters
What GRASS version and platform?
Maciek
Elev1-10 min = -340282346638528859811704183484516925440.000000
(surprising to me, same for all)
1 max = 879.000000
2 max=3128.000000
3 max=3066.000000
4&5 max=1894.000000
6 max=1877.000000, 7 max= 3300.000000
8 max=979.0000000, 9 max= 3442.000000
10 max =963.000000 - eleventh file cannot be read (apologies, it
was an extra file)
Presuming null values as neg to pos, min to max, indicates so.
The inidvidual rasters display properly individually via command line as
well as via gui.
-----Original Message-----
From: Maciej Sieczka [mailto:tutey@o2.pl]
Sent: Monday, July 16, 2007 12:11 PM
To: Daniel Farnan @ San Francisco
Cc: GRASSLIST
Subject: Re: [GRASS-user] One raster from many
Daniel Farnan @ San Francisco wrote:
Worked much faster than 4 days, but generated a blank (white) raster.
- this may be due to the srtm data(?). All were imported as .tif with
r.in.gdal.
Please don't reply in priv when other users might benefit from the
discussion or be able to help you.
What is each raster's min-max (r.info -r)? Is null present?
When you set the region to cover them all (g.region
rast=rast1,rast2,...,rast11 -a), do you see what you expect when you do:
d.mon x0
d.rast one_of_the_rasters
What GRASS version and platform?
Maciek
Daniel Farnan @ San Francisco wrote:
Elev1-10 min = -340282346638528859811704183484516925440.000000
(surprising to me, same for all)
Presumably, you should set this strange neg value to null; using
r.null. What are the min values then? Does r.patch work as expected now?
Maciek
Daniel Farnan @ San Francisco wrote:
Elev1-10 min = -340282346638528859811704183484516925440.000000
(surprising to me, same for all)
If that value is represented in IEEE single precision format (i.e. C's
"float" type), the binary representation is 0xff7fffff, which is
presumably meant to be the null/no-data value.
--
Glynn Clements <glynn@gclements.plus.com>
thanks, that makes more sense than trying to bridge the null values
from so large a negative number to 0 in r.null - appears to be working
with r.null now - will have to set the other files before r.patch-ing
again.
-----Original Message-----
From: Glynn Clements [mailto:glynn@gclements.plus.com]
Sent: Monday, July 16, 2007 4:58 PM
To: Daniel Farnan @ San Francisco
Cc: grassuser@grass.itc.it
Subject: RE: [GRASS-user] One raster from many
Daniel Farnan @ San Francisco wrote:
Elev1-10 min = -340282346638528859811704183484516925440.000000
(surprising to me, same for all)
If that value is represented in IEEE single precision format (i.e. C's
"float" type), the binary representation is 0xff7fffff, which is
presumably meant to be the null/no-data value.
--
Glynn Clements <glynn@gclements.plus.com>
Hurray, thank you very much Glynn, and Maciek!
Success.
R.null and r.patch have worked with the null-ing of the unusual min
value for the rasters - I am surmising this is an SRTM issue from
previous e-mails, and other input on Radar data's reliability and
nature. I never would have figured this out.
Thanks again.
Daniel
-----Original Message-----
From: Glynn Clements [mailto:glynn@gclements.plus.com]
Sent: Monday, July 16, 2007 4:58 PM
To: Daniel Farnan @ San Francisco
Cc: grassuser@grass.itc.it
Subject: RE: [GRASS-user] One raster from many
Daniel Farnan @ San Francisco wrote:
Elev1-10 min = -340282346638528859811704183484516925440.000000
(surprising to me, same for all)
If that value is represented in IEEE single precision format (i.e. C's
"float" type), the binary representation is 0xff7fffff, which is
presumably meant to be the null/no-data value.
--
Glynn Clements <glynn@gclements.plus.com>