[FOSSGIS-Talk] Digitales Geleändemodell

Markus Neteler neteler at osgeo.org
So Jul 15 18:04:04 CEST 2012


2012/7/14 Torsten Eckart <torecki at arcor.de>:
> Markus:
>> Es ist 4326: http://spatialreference.org/ref/epsg/4326/

> Oh, ok. Ich sehe da noch nicht ganz durch. Auf der grasswikiseite steht,
> dass sich eine latlon location eignet grass will aber noch eine
> projektion und da hatte ich die gewählt in der Hoffnung richtig zu liegen.

Es *muss* aber 4326 sein, sonst kommt evtl Unsinn heraus...:
also Lat-Long WGS84.

>>> Ich war aber nicht in der Lage wie in
>>> http://grass.osgeo.org/wiki/HOWTO_import_SRTM_elevation_data
>>> beschrieben mehrere Dateien gleichzeitig zu laden.
>>
>> Inwiefern? Kann man helfen?
> Das sieht bei mir anders aus als auf dem screenshot. Wenn ich die
> hgt-files aus einem Verzeichniss laden will bietet mir grass nicht an
> die einzelnen files zu wählen und er lädt auch nichts aus dem
> Verzeichnis. Siehe angehängten Screenshot.

Aha, es scheint eine aeltere (?) GRASS Version zu sein.

In GRASS 6.4 sieht der Dialog so aus:
http://grass.osgeo.org/wiki/File:WxGUI_bulk_srtm_import.jpg
--> es gibt ein "Extension" (Erweiterung) Feld, in dem "hgt" eingegeben
      werden kann.

>> Alternativ lohnt es sich auch, mit gdalwarp alle Tiles in eine Karte
>>  zu bringen:
>>
>> gdalwarp SRTM*.HGT mosaik.tif
> Das klappt super, Danke.

Gut.

>>> Die Daten, z.B. Linien von Wegen, möchte ich im Relief darstellen.
>>>  Wie mache ich das?
>>
>> In GRASS: - r.shaded.relief DEM (fuer Reliefschummerungskarte) - GUI
>>  oder NVIZ zum anschauen
> Die Ansicht im nviz sieht sehr unnatürlich aus. Wahrscheinlich muss man
> da noch etwas an den Parametern ändern.

3D in LatLong ist nicht einfach zu handhaben.
Ich empfehle daher, eine metrische Projektion zu nehmen (GK, UTM, EU-LAEA).

> Muss ich nicht noch etwas mit dem Mosaik machen?

Muessen nicht :) Aber es hat sicherlich Loecher, da es Seitensicht-Radar
basiert erstellt wurde (Schattenwirkung macht Loecher).

> Ein r.fillnulls ergibt:
> Fri Jul 13 11:20:53 2012)
> r.fillnulls input=srtmMosaik at PERMANENT output=srtmMosaikFillnulls at PERMANENT
> Locating and isolating NULL areas...
> Lese Eingabe-Rasterkarte <r_fillnulls_5690 at PERMANENT>...
> Schreibe Ausgabe-Rasterkarte <r_fillnulls_5690.buf>...
...
> Verstehe ich das richtig, dass es keine 0 Werte im Mosaik gibt?

In jedem Fall muss vorher die aktuelle Region auf die Karte gesetzt
werden:

g.region rast=srtm -p

Ob dann Loecher drin sind oder nicht, sagt z.B.

r.univar srtm

...
> Wenn ich eine neue location mit dem EPSG-code 3397 erzeuge fragt grass
> mich welche Datumstransformation ich wählen möchte. Das finde ich super.
> Woher kommen diese Parameter?

Aus einer oeffentlichen Datumstransformation-Datenbank:
http://www.crs-geo.eu

> Warum hat Thüringen eine von den anderen
> verschiedene Transformation?

Das wissen die Geodaeten :)

http://www.crs-geo.eu/nn_124226/crseu/EN/CRS__Description/crs-national__node.html?__nnn=true
--> DE_PD/83 / GK_3

> Unter 3 findet sich eine Transformation für Thüringen die sich von den
> anderen Transformationen unterscheidet.

Ja, es soll eben fuer Thüringen optimiert sein.

> Ich nehme die mal in der Annahme
> das richtige zu tun. Beim import der gelieferten *.shp Dateien schreibt
> grass:
> Datum <Not_specified_based_on_Bessel_1841_ellipsoid> nicht erkannt von
> GRASS und keine Parameter gefunden.

OK, haben die SHAPE Dateien auch die (korrekten) .prj Dateien?
Die fehlen naemlich gerne mal, auch wenn sie natuerlich immer
mitgeliefert werden sollten. In dem Fall kann auch GRASS nicht
viel machen...

> Die Projektionsinformationen des Eingabedatensatzes und der aktuellen
> Location scheinen übereinzustimmen.

Wunderbar.

>> http://grass.osgeo.org/wiki/GRASS_Location_Wizard - dann die Karte
>> aus der Latlong-location in die metrische Location reinprojizieren
>> (r.proj in der metrischen Loc. benutzen, fuer DEM bilinear Methode
>> nehmen)
> Ich habe mir mit r.proj die Region für das Raster in der Ziellocation
> anzeigen lassen und diese mit g.region geändert. Danach scheint der
> import mit r.proj und der bilinaren Methode zu klappen es dauert aber ewig.

Das kann drei Gruende haben:
- die Karte ist riesig (also Geduld)
- die Zielaufloesung ist nicht korrekt (g.region res=XX -p)
- sehr viel No-data um die eigentliche Karte herum wird mittransformiert (also
  sollte die aktuelle Region korrigiert werden)

Gruesse
Markus