I think there's something I don't know about how Digital Elevation Models work.
I have imported models from srtm.csi.cgiar.org, using ASCII downloads. To import the models, I'm using r.in.gdal.
If I import the model to a new location, everything looks fine, and if I query the imported map, I get results that make sense. For eg:
r.what -f input=testdem@PERMANENT east_north=151.3524554,-30.85835173
returns:
151.3524554 -30.85835173 1026
(I have taken out the | delimiters to make it more legible)
But if I then import a different DEM tile from the same site, in the same format, and load it into the same location, it loads without the elevation. Hence:
r.what -f input=DEM2@PERMANENT east_north=119.2521986,-30.56112713
returns results like:
119.2521986 -30.56112713 *
If I load the second DEM into a new location, it will work fine but no other DEMs will show their elevation data.
Can anyone provide suggestions as to the likely cause?
I have imported models from srtm.csi.cgiar.org, using ASCII downloads.
To import the models, I'm using r.in.gdal.
If I import the model to a new location, everything looks fine, and if I
query the imported map, I get results that make sense. For eg:
r.what -f input=testdem@PERMANENT east_north=151.3524554,-30.85835173
returns:
151.3524554 -30.85835173 1026
(I have taken out the | delimiters to make it more legible)
But if I then import a different DEM tile from the same site, in the
same format, and load it into the same location, it loads without the
elevation. Hence:
r.what -f input=DEM2@PERMANENT east_north=119.2521986,-30.56112713
returns results like:
119.2521986 -30.56112713 *
If I load the second DEM into a new location, it will work fine but no
other DEMs will show their elevation data.
Can anyone provide suggestions as to the likely cause?
"*" as a value indicates that the value of that cell is NULL. One
possible/ probable reason for that is if the map is outside of the
current region. Anything off the end of the map will be reported as NULL.
That's the raw value of the data, nothing to do with color settings,
those are applied later.
try "g.region -p rast=DEM2" to set the current region to the map's
extents. Also,
g.region -p rast=DEM1,DEM2
will zoom to a region which covers both maps.
I feel a forehead-slapping moment coming on... to see if I get this:
1) Import DEM (say, East Coast of Australia) to new location creates a region with the extents of the DEM.
2) Import second DEM which is outside the region of the first DEM = null values *because* it's outside the original extents.
I think I'm with you ... tomorrow I will try your suggestions. Many thanks, as always!
Richard Chirgwin
Hamish wrote:
Richard Chirgwin wrote:
I have imported models from srtm.csi.cgiar.org, using ASCII downloads. To import the models, I'm using r.in.gdal.
If I import the model to a new location, everything looks fine, and if I query the imported map, I get results that make sense. For eg:
r.what -f input=testdem@PERMANENT east_north=151.3524554,-30.85835173
returns:
151.3524554 -30.85835173 1026
(I have taken out the | delimiters to make it more legible)
But if I then import a different DEM tile from the same site, in the same format, and load it into the same location, it loads without the elevation. Hence:
r.what -f input=DEM2@PERMANENT east_north=119.2521986,-30.56112713
returns results like:
119.2521986 -30.56112713 *
If I load the second DEM into a new location, it will work fine but no other DEMs will show their elevation data.
Can anyone provide suggestions as to the likely cause?
"*" as a value indicates that the value of that cell is NULL. One
possible/ probable reason for that is if the map is outside of the
current region. Anything off the end of the map will be reported as NULL.
That's the raw value of the data, nothing to do with color settings,
those are applied later.
try "g.region -p rast=DEM2" to set the current region to the map's
extents. Also,
g.region -p rast=DEM1,DEM2
will zoom to a region which covers both maps.
And to conclude this story, Hamish: Thanks, the fix worked fine.
So there may be something to put in the manuals? If someone wants this written, I am happy to do so, as long as someone tells me which manual page this should be added to (so I can fit it in context!).
Richard Chirgwin
Hamish wrote:
Richard Chirgwin wrote:
I have imported models from srtm.csi.cgiar.org, using ASCII downloads. To import the models, I'm using r.in.gdal.
If I import the model to a new location, everything looks fine, and if I query the imported map, I get results that make sense. For eg:
r.what -f input=testdem@PERMANENT east_north=151.3524554,-30.85835173
returns:
151.3524554 -30.85835173 1026
(I have taken out the | delimiters to make it more legible)
But if I then import a different DEM tile from the same site, in the same format, and load it into the same location, it loads without the elevation. Hence:
r.what -f input=DEM2@PERMANENT east_north=119.2521986,-30.56112713
returns results like:
119.2521986 -30.56112713 *
If I load the second DEM into a new location, it will work fine but no other DEMs will show their elevation data.
Can anyone provide suggestions as to the likely cause?
"*" as a value indicates that the value of that cell is NULL. One
possible/ probable reason for that is if the map is outside of the
current region. Anything off the end of the map will be reported as NULL.
That's the raw value of the data, nothing to do with color settings,
those are applied later.
try "g.region -p rast=DEM2" to set the current region to the map's
extents. Also,
g.region -p rast=DEM1,DEM2
will zoom to a region which covers both maps.
I feel a forehead-slapping moment coming on... to see if I get this:
1) Import DEM (say, East Coast of Australia) to new location creates a
region with the extents of the DEM.
2) Import second DEM which is outside the region of the first DEM = null
values *because* it's outside the original extents.
r.in.* modules will (ie should generally) ignore the region settings. On
the other hand, r.proj and GeoRect tools may observe the region settings
(e.g. to pick target resolution). It may not be strictly necessary, but
for those I usually first do v.in.region+v.proj then in the target
location zoom to that projected bounding box and make sure the rows/cols
are a nice round number slightly more than in the source region so no
information is lost. If true-north is rotated between the two projections
you'll need to be more than the original rows/cols, as the original cells
are now along a hypotenuse. see i.rectify bug # 3166 (3rd order transform) https://intevation.de/rt/webrt?serial_num=3166
I go to this trouble as I'm still confused by the region cropping
algorithms and can never remember which of the bugs have been fixed or
not, so I use that method and it works. Probably it's not needed, but I
prefer the comfort of overkill. I don't claim it is the correct method to
use.
After import with r.in.* you will need to change the computational
region's zoom to cover that new data if you want to see/process it.
(g.region)
And to conclude this story, Hamish: Thanks, the fix worked fine.
So there may be something to put in the manuals? If someone wants this
written, I am happy to do so, as long as someone tells me which manual
page this should be added to (so I can fit it in context!).