Vergleich der Höhenlinien in Österreichkarten

Interessant. Für meine Karten benutze ich phyghtmap. Das Programm holt die Höhendaten von viefinderpanoramas. Mir scheint allerdings, als wenn mein 2000er Kringel etwas verrutscht ist. Wie man das wohl korrigieren kann?
[Blockierte Grafik: https://fstatic1.mtb-news.de/v3/23/2317/2317931-knjimensobjf-rokopfspitze-large.png]

Ich hab noch keine Karte gefunden, die das Potential der österreichischen 10x10m Lidardaten voll ausschöpft. Grund dafür scheint zu sein, dass einerseits das oft verwendete phyghtmap damit nicht umgehen kann und andererseits der Speicherbedarf enorm anwächst. Man könnte also keine komplette Alpenkarte rendern.

Um den Unterschied zu demonstrieren hab ich einen Graben geeigneter Größe genommen. Damit sieht man das deutlicher als etwa bei Bergspitzen. Die Diskussion dazu ist im OAM Forum

phyghtmap hat eine Korrektur-Option Damit bekomme ich die Höhenlinie genau um den Gipfel. Allerdings passt der Nachbargipfel dann nicht mehr. Auch andere Gipfel liegen selten genau im Kringel. Egal ob mit oder ohne Korrektur.

In phyghtmap habe ich die Daten von Sonny gesteckt und die Austriakarte damit hergestellt. Ein großer Unterschied ist nicht zu sehen. Kann es sein, dass Viewfinder die gleichen Daten wie Sonny verwendet?

Die Viewfinder Daten stammen ursprünglich aus der Digitalisierung der Höhenlinien der russischen topografischen Militärkarten. Diese haben wohl ebenso wie die Daten von Sonny eine gute Qualität, so dass mich nicht wundert, wenn sie ähnliche Resultate liefern. Die Auflösung ist doch durch phyghtmap auf 1" begrenzt, oder? Also die 20m Daten von Sonny kann man damit nicht verwenden.

Zitat von Wolfgang16

... Die Auflösung ist doch durch phyghtmap auf 1" begrenzt, oder? .....

Mir fehlen da die technischen Hintergründe.
Man kann den Höhenlinienabstand festlegen. Ich verwende in meinen Karten derzeit 20m Abstand. Man kann aber auch 10m einstellen. Wie phyghtmap dass dann macht, weiß ich nicht.

Ich fürchte ihr bringt hier das Rastermaß (horizontaler Abstand bzw Auflösung der "Messpunkte") und die Äquidistanz (Höhenunterschied zwischen zwei benachbarten Höhenlinien) durcheinander.

Mit "Auflösung" meine ich den horizontalen Gitterabstand der Daten. Sonny bietet ja an 1"x1" im .hgt Format ( also wie SRTM ) oder 20x20m als GeoTIFF. Welche hast du denn in das phyghtmap gesteckt? Ich hab leider noch nie mit phyghtmap gearbeitet, daher stehe ich da jetzt auch auf dem Schlauch.

Die hgt Daten. Was anderes geht mit phyghtmap nicht, soweit ich weiß..

Abstand ist natürlich Blödsinn. Ich meine den Höhenunterschied zwischen den Linien.

Bei den mit mkgmap erzeugten Garminkarten werden die hgt Daten 2 Mal benutzt. Einmal werden über den Umweg phyghtmap die Höhenlinien erzeugt. Die Schummerung stellt mkgmap direkt aus den hgts her

Gibt es eine Alternative, Höhendaten in Höhenlinien umzurechnen, damit mkgmap das verarbeiten kann?

Ich habe noch mal ein wenig in meiner Region mit den Sonny-Daten herumgespielt. Da es hier im Bergischen nicht so bergig ist, habe ich als Höhenunterschied zwischen den Linien 10m ausgewählt. Daher hinkt der Vergleich im folgenden Bild etwas, da ich mit einer Karte mit 20m Abstand vergleiche, aber man doch erkennen, dass bei diesem See die Sonny Daten wesentlich besser sind als diejenigen von viewfinder. N51° 15.024' E7° 03.257'

[Blockierte Grafik: https://fstatic1.mtb-news.de/v3/23/2319/2319320-rm2a1qddwukl-loch-large.jpg]

Zitat von Speichennippel

...Gibt es eine Alternative, Höhendaten in Höhenlinien umzurechnen, damit mkgmap das verarbeiten kann?

Ja mehrere. Die ältere ist Dem2Topo mit der IDL-VirtualMachine. Moderner und automatisierbar ist Global Mapper. Mit GlobalMapper kannst du per GlobalmapperScriptfile im batchmodus aus den hgt (oder anderen von GM unterstützten Formaten wie GeoTiff) Höhenlinien als .mp -File generieren. Und diese mp-Files werden von mkgmap genauso eingelesen wie die .pbf . Ein 1°x1° Höhenlinien- mp Tile wird von mkgmap in wenigen Sekunden compiliert, also sauschnell. Ein gewisses Problem dabei ist nur, dass die Höhenlinien dann als extra-Layer in der Karte existieren und die Problematik der Zeichenreihenfolge in Mapsource existiert. BC hat das Problem nicht. In Screenshot ist solche eine Karte, links in MS und rechts in BC. Man sieht , dass die Grafikmachine von MS die Höhenlinien bei Benutzung von Typfiles nicht immer darstellen kann, es gibt Bereiche , wo die fehlen und andere, wo die da sind; nur die zugehörigen Beschriftungen werden gezeigt. In dem Bildausschnitt fehlen die vollständig. In BC ist alles okay
Das GlobalMapperScript-format ist ausführlich in der GM -Hilfe beschrieben. Hier mal ein Beispiel für 2 Kacheln :

GLOBAL_MAPPER_SCRIPT VERSION=1:00
UNLOAD_ALL
IMPORT FILENAME="D:\Thomas Daten\KARTEN\HGT -Files\N47E006.hgt.zip"
GENERATE_CONTOURS ELEV_UNITS=METERS INTERVAL=20 GEN_SPOT_ELEVATIONS=YES
EXPORT_VECTOR FILENAME="D:\Thomas Daten\KARTEN\HGT -Files\N47E006.mp" TYPE=POLISH_MP MAP_NAME=Hoehenlinien
UNLOAD_ALL
IMPORT FILENAME="D:\Thomas Daten\KARTEN\HGT -Files\N47E007.hgt.zip"
GENERATE_CONTOURS ELEV_UNITS=METERS INTERVAL=20 GEN_SPOT_ELEVATIONS=YES
EXPORT_VECTOR FILENAME="D:\Thomas Daten\KARTEN\HGT -Files\N47E007.mp" TYPE=POLISH_MP MAP_NAME=Hoehenlinien
 UNLOAD_ALL

Ich schreibe mir aber die scripts nicht von Hand, sondern lasse die Scripts wegen der große Anzahl von Tiles mit einer VBA-Routine automatisch generieren.

morgen1

Zitat von Speichennippel

N51° 15.024' E7° 03.257'

Die Viewfinder haben natürlich auch eine unterschiedliche Qualität. Die russischen Karten gab es in den Alpen bis runter auf 1:50.000. Im Bergischen Land war das wohl nicht der Fall. An dem See zeigt meine NRW Karte noch einen Kalksteinbruch. Wie der Ersteller der Viewfinder mit solchen Veränderungen umgeht, weiß ich nicht.

Im rechten Bild sind die Viewfinder, oder? Das rechte Bild sieht schon allein deswegen schlechter aus, weil die Höhenlinien nur aus wenigen Punkten bestehen.

Meine Höhenlinien hab ich mit GlobalMapper erzeugt. Da kann man schön mit den Parametern spielen und das gleich visuell überprüfen. Das kann auch die Tiroler oder Vorarlberger Höhendaten direkt lesen und kann OSM schreiben. Das OSM muss man dann noch ein bischen editieren und kann das dann über Osmosis mit den anderen OSM Daten zusammenführen. Das geht, wie morgen1 schon schrieb, über Script.

Spontan als Alternative fällt mir nur noch gdal_contour ein. GDAL kann zahlreiche Formate lesen und schreiben, nur kann es (im Gegensatz zu Globalmapper) leider kein OSM schreiben. QGIS in Verbindung mit GRASS GIS wäre noch eine Alternative; QGIS kann OSM schreiben.

Zitat von morgen1

..... Global Mapper.....ist nur, dass die Höhenlinien dann als extra-Layer in der Karte existieren und die Problematik der Zeichenreihenfolge in Mapsource existiert. BC hat das Problem nicht......

Mit der Einschränkung in MapSource kann ich leben, da ich alles in BaseCamp mache. Die Sache hat aber ein gravierenderes Problem: Also extra Layer werden die Höhenlinien fast immer über den anderen Wegen gezeichnet. Das sieht nicht nur scheußlich aus, es leidet vor allem die Ablesbarkeit. Ist aber auch ein wenig vom Typ der Wege abhängig, ob das übermalen stört oder nicht.

Ich werde mich das GlobalMaper trotzdem anschauen, danke für den Tip.

Zitat von Wolfgang16

....kann OSM schreiben. Das OSM muss man dann noch ein bischen editieren und kann das dann über Osmosis mit den anderen OSM Daten zusammenführen. Das geht, wie morgen1 schon schrieb, über Script.

Spontan als Alternative fällt mir nur noch gdal_contour ein. GDAL kann zahlreiche Formate lesen und schreiben, nur kann es (im Gegensatz zu Globalmapper) leider kein OSM schreiben. QGIS in Verbindung mit GRASS GIS wäre noch eine Alternative; QGIS kann OSM schreiben.

Mit Osmosis habe ich es noch nie geschafft, etwas damit zu machen. Irgendwie bin zu blöd dazu.

Mir ist aber auch nicht klar, weshalb man die OSM-Daten und die Höhendaten zusammenfügen sollte. mkgmap-splitter verarbeitet beides gleichzeitig zu einer Karte. Es gibt dann auch kein Problem mit MapSource und der Zeichenreihenfolge.

Das Qgis werde ich mir auch einmal angucken, danke!

Zitat von Speichennippel

.... mkgmap-splitter verarbeitet beides gleichzeitig zu einer Karte. Es gibt dann auch kein Problem mit MapSource und der Zeichenreihenfolge.

Jetzt muss ich was dazu lernen und fragen: hgt' s und Höhenlinien daraus im mp-Format liegen als 1°x1° Tiles vor, die OSM als europe-latest.pbf. Wie lautet die commandline, damit splitter die europe-latest.pbf entsprechend bestehender europa.list und zusätzlich die hgt (oder mp ?) mit in die Tiles splittet ? Wenn ich bei mkgmap 2 Kacheln angebe, dann macht mir mkgmap immer 2 Tiles draus, zumal die OSM und hgt /mp auch unterschiedliche geografische Grenzen haben. Aus den kompilierten Tiles, sowohl die OSM als auch die Höhenlinien dann 1 Karte zu machen, ist kein Problem. Aber es wäre schon interessant , Tiles zu haben, die auch die Höhenlinien gleich mit drin haben, statt extra. Und das ohne erst mit osmosis zu mischen. geht das ?

morgen1

Zunächst habe ich mit phyghtmap SRTM.pbf machen lassen.
Der Aufruf von splitter ist dann total simpel:

splitter OSM.pbf SRTM.pbf

So rufe ich das vollständig auf:
"java" -jar -Xmx7500M .\Tools\splitter\splitter.jar --max-threads=2 --mapid=!MapID[%zln%]! --precomp-sea=.\Daten\sea.zip --geonames-file=.\Daten\cities1000.txt --max-nodes=1048576 --max-areas=512 --keep-complete=true --write-kml=splitter.kml --output-dir=.\Baustelle\!Name[%zln%]!_Splitter .\OSM\!Name[%zln%]!.osm.pbf .\SRTM\SRTM_!Name[%zln%]!.pbf > nul

Die Gebiete müssen nicht deckungsgleich sein. Man kann OSM Frankreich mit SRTM Deutschland bauen, was natürlich sinnlos ist, aber splitter macht das, ohne zu klagen.

Zitat von morgen1

... Aus den kompilierten Tiles, sowohl die OSM als auch die Höhenlinien dann 1 Karte zu machen, ist kein Problem......

Aus den Tiles, die aus splitter kommen oder aus mkgmap?

Eine fertige Karte und eine fertige Höhenlinienkarte bekomme ich nicht sinnvoll zusammengebacken. Entweder die Höhenlinien liegen über den Weg, was blöd aussieht, oder man kann die Karte nicht anklicken, weil die Höhenlinienkarte im Weg ist. Es fehlt dann praktisch diese Sprechblase:
[Blockierte Grafik: https://fstatic1.mtb-news.de/v3/23/2319/2319551-fzd48mdp60ae-quickinfo-medium.jpg]