0

I want to use interpolated SRTM data for Germany to generate an STL terrain map for use in a CFD application.

My SRTM data comes from the OpenDEM project. SRTM data normally has voids, but this data has been assembled from multiple tiles and the voids filled with other DEM data and through interpolation.

The DEM is in the form of a TIFF, which I am presuming is a GeoTIFF since I've yet to see any other GIS TIFF formats.

When I import the TIFF into GRASS, everything seems to work at first:

(Sat Aug 31 23:22:22 2013)                                                      
r.in.gdal input=/home/sfbosch/Documents/Quelle/OpenFOAM/GIS/srtm_germany_dtm/srtm_germany_dtm.tif output=srtm_germany_dtm
Projection of input dataset and current location appear to match
r.in.gdal complete. Raster map <srtm_germany_dtm> created.
(Sat Aug 31 23:22:28 2013) Command finished (5 sec)

The moment I try to make the layer visible in the Layer Manager, though, I get an error:

Command 'd.rast -o map=srtm_germany_dtm@PERMANENT' failed
Details: region for current mapset line 4: <north:
371149.387386>
run "g.region"

The image does not appear in the GIS Map Display window. My first thought was, I've imported the data incorrectly, or there's something wrong with it. But when I use QGIS with the GRASS plugin to access the very same layer and set Contrast Enhancement to "Stretch to MinMax", there it is (though I would like to know why the top half is so dark):

The GRASS SRTM layer in QGIS

Why does it work in one, and not the other? Unfortunately, it's not good enough that it works in QGIS -- I need to get this working in GRASS because the Python script I am using to generate the STL file depends on it.

One clue might be that, when I move the cursor over the (blank) Map Display window in GRASS after rendering the layer and getting the error message, I can't make any sense of the coordinates. They seem to be in some mish-mash of UTM and LatLon, and they are not consistent. The numbers jump all over the place.

If I get the region, here's what comes out:

(Sat Aug 31 23:49:02 2013)                                                      
g.region -p                                                                     
projection: 3 (Latitude-Longitude)
zone:       0
datum:      wgs84
ellipsoid:  wgs84
north:      56:00:01.5N
south:      0:59:58.5S
west:       0
east:       17E
nsres:      1
ewres:      1
rows:       57
cols:       17
cells:      969
(Sat Aug 31 23:49:02 2013) Command finished (0 sec)

I'm using GRASS GIS 6.4.3, QGIS 1.8.0, GDAL 1.9.2 on Gentoo Linux 3.7.9-gentoo x86_64.

Improve this question
2
  • Is this projection specific? Have you tried to reproject it into sth. like Gauß-Krüger or a UTM projection?
    – Curlew
    Commented Aug 31, 2013 at 22:45
  • @Curlew No, I haven't tried that. How would I do that? Btw: I tried importing ASTER data, and I get the same behaviour: it works in QGIS via GRASS-plugin, but not in GRASS itself.
    – Stephen Bosch
    Commented Aug 31, 2013 at 23:31

2 Answers 2

Reset to default
1

This behaviour appears to be the result of a bug in the wxPython GUI for GRASS GIS 6.4.3. If I save the workspace and close GRASS, then restart, the layers display properly.

This might also explain why it works right away in QGIS.

Improve this answer
3
  • Nice to know. If you have the time for it you could raise a bug-report (if not already existing) and look if the bug still exists in grass 7
    – Curlew
    Commented Sep 1, 2013 at 23:00
  • I see in the original post "Details: region for current mapset line 4: <north: 371149.387386>" which looks suspicious. First you need to set the region to the map, then look at it (there is a zoom-to-map entry in the right mouse button menu for this). Don't see a bug yet.
    – markusN
    Commented Sep 1, 2013 at 23:30
  • 1
    @markusN That still doesn't explain why it works after restarting; in both cases it uses the default region.
    – Stephen Bosch
    Commented Sep 1, 2013 at 23:34
0

You can also try right clicking in the map tree and selecting "Zoom to Selected Map(s)". It seems like the bug places the viewer at coordinates 0,0 and that is unlikely where your SRTM file is located. Zooming will place you in the right spot.

Improve this answer
1
  • 1
    This answer has been flagged up as of low quality due to its length. I've asked to have the flag removed but to avoid future flags perhaps you can try to always write a couple of sentences when answering e.g. add why you are suggesting something if that something is a one liner.
    – PolyGeo ♦
    Commented Jan 9, 2014 at 22:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.