Beiträge von kiozen

Das bezog sich auf "dass der Herr am Anfang noch Basecamp nutzt mit dem H1"

Zitat von Alpsee

Hier noch ein weiteres Video aus England zum H1plus. Interessant, dass der Herr am Anfang noch Basecamp nutzt mit dem H1 .

Na ja das richtige Alter dazu hat er ja...

Cool, Kartenstapel

Kartenspiele mit QMapShack

Unversehens ist hier eine kleine Artikelserie zu QMapShack entstanden. Dieses Mal geht es um das Arbeiten mit mehreren Karten.

gnulinux.ch

So sieht das übrigens mit 1x1m Höhendaten und Schummerung aus (DGM1)

Das Interessante bei der Auflösung ist, das man sogar historische Wege bzw Rückergassen erkennen kann.

Die DOM1 Daten erfassen die Vegetation und Bebauung.

DOM1 ist jetzt sicherlich für die Meisten eher uninteressant.

joa, dann würde ich es gut sein lassen. Etwas komisch, aber wenn es richtig aussieht.

Und wie sieht die Stelle in QMS aus?

Zitat von beedaddy

Ich habe die vorherige vrt-Datei immer gelöscht und "frisch" angefangen. Die Fehlermeldung kommt bei beinahe allen Kacheln. Tatsächlich sieht so eine Kachel aber sowohl in GIMP als auch in QMapShack ok aus. 🤷‍♂️

Die VRT ist auch nicht das Problem. Die sollte mit jedem Aufruf von gdalbuildvrt neu gebaut werden. Die Farbtabellen in den TIFF Dateien sind wichtig. Die kann man mit gdalinfo ansehe. Du kannst ja mal die erster Datei die prozessiert wird mit der ersten die einen Fehler wirft vergleichen.

Eigentlich sollten die alle gleich sein. Die kommen ja aus der selben Karten, mit den selben Farben. Deswegen ist das etwas komisch.

Leider ist für diese Art von Karten TIFF mit Farbtabelle im Kompressionsgrad unschlagbar. jede Expansion in den RGB Farbraum, auch mit JPEG Kompression, kommt da nicht ran. Ist die gute alte Lauflängenkompression vom Fax doch noch für was gut

Bei Fragen kann geholfen werden

Zitat von beedaddy

VRT Builder:

• Einstellung "Übersichtsebenen erstellen" deaktiviert bringt Fehlermeldungen wie etwa: `Warning 6: /home/brodbemn/Dokumente/QMapShack/Karten/DTK25BW/dtk25_32545_5320_5_bw_col.tif has different values than the first raster for some entries in the color table.`
• Einstellung "Übersichtsebenen erstellen" aktiviert beseitigt diese Fehlermeldungen, selbst wenn darunter (":2", ":4", …) nichts ausgewählt wird.
• Verschiedene Auswahlen von :2, :4, usw. (manche, alle, keine) scheinen nicht wirklich einen Unterschied zu machen.

Sprich, ich muss noch viel ausprobieren und nachlesen und nochmal ausprobieren.

Also die Fehlermeldung sagt Folgendes: Wir verwenden hier Tifs mit einer Farbtabelle. Diese Farbtabelle wird aus der ersten Kachel extrahiert und in der VRT Datei abgelegt. Sollte jetzt eine der nachfolgenden Kacheln eine andere Farbtabelle haben, kommt diese Fehlermeldung.

Hintergrund: Theoretisch müsste GDAL für jede Datei die Farbtabelle lesen und dann für diese Datei speziell verwenden. Das kostet Zeit. In der Regel haben solche Kachelsammlungen alle die selbe Farbtabelle. Deswegen legt man die in der VRT Datei ab und verwendet sie für alle Dateien.

Speziell in deinem Fall hat die Datei dtk25_32545_5320_5_bw_col.tif eine andere Farbtabelle. Warum kann ich nicht sagen. Entweder die Kachel hat wirklich diesen "Fehler" oder es ist ein Überbleibsel aus deinen Experimenten und die Datei gehört nicht wirklich zu dem Satz.

Warum das mit den Übersichtsebenen verschwindet wundert mich auch. Schau dir lieber mal die Kachel direkt an und dann in QMS. Sollte das passen -> einfach ignorieren.

Keine Ahnung wie weit Du die Artikelserie treiben willst, aber da gäbe es ja noch sooo viel zu zeigen. z.B. wirklich die Kartenstapel. Sprich die Karten 1:10000, 1:25000 etc so einstellen dass die jeweils nur bei den besten Zoomstufen gezeigt werden. Das Ganze als Dateien->Kartenansicht speicher damit man es immer wiederherstellen kann, sollte man die Ansicht aus Versehen schließen.

Oder mehrere Kartenansichten verbinden (müssen dann alle die selbe Projektion und Zoomskala verwenden) Dann kann man seine Touren einfach parallel auf einer Topokarte, einer Garminkarte und auf einer Satellitenkarte anzeigen und zwischen den Ansichten hin- und herspringen. Auch sehr praktisch.

Ah, ich sehe die Früchte dieser Diskussion hier

QMapShack: Topografische Karten einbinden

Wer lieber mit topografischen Karten arbeitet, findet hier Hinweise, man diese in QMapShack einbinden kann – so sie denn als Open Data verfügbar sind.

gnulinux.ch

Und jetzt noch die 1:10000 Karte und einen Kartenstapel bauen

Ja kann man. Das Problem ist, dass die TFW Datei nur die Transformationsmatrix beinhaltet. Nicht die Projektion. Die müsste in einer weiteren Datei mit der Endung *.prj stehen.

Frag mich nicht warum das in DE immer alles so kompliziert abgelegt wird. Ein simples GEOTiff würde es ja auch tun.

GDAL kommt damit zurecht wenn es die drei Dateien (*.tif, *.tfw, *.prj) mit dem selben Namen findet. Das kann man auch verifizieren indem man

gadalinfo <dateiname>.tif 

aufruft. Wenn das ungefähr so aussieht

gdalinfo DTM\ Austria\ 20m.tif 
Driver: GTiff/GeoTIFF
Files: DTM Austria 20m.tif
Size is 29729, 15807
Coordinate System is:
PROJCRS["ETRS89 / UTM zone 33N (N-E)",
    BASEGEOGCRS["ETRS89",
        DATUM["European Terrestrial Reference System 1989",
            ELLIPSOID["GRS 1980",6378137,298.257222101004,
                LENGTHUNIT["metre",1]]],
        PRIMEM["Greenwich",0,
            ANGLEUNIT["degree",0.0174532925199433]],
        ID["EPSG",4258]],
    CONVERSION["UTM zone 33N",
        METHOD["Transverse Mercator",
            ID["EPSG",9807]],
        PARAMETER["Latitude of natural origin",0,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8801]],
        PARAMETER["Longitude of natural origin",15,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8802]],
        PARAMETER["Scale factor at natural origin",0.9996,
            SCALEUNIT["unity",1],
            ID["EPSG",8805]],
        PARAMETER["False easting",500000,
            LENGTHUNIT["metre",1],
            ID["EPSG",8806]],
        PARAMETER["False northing",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8807]]],
    CS[Cartesian,2],
        AXIS["easting",east,
            ORDER[1],
            LENGTHUNIT["metre",1]],
        AXIS["northing",north,
            ORDER[2],
            LENGTHUNIT["metre",1]],
    ID["EPSG",3045]]
Data axis to CRS axis mapping: 1,2
Origin = (78136.546042963629588,5445535.252411518245935)
Pixel Size = (20.000000000000000,-20.000000000000000)
Metadata:
  AREA_OR_POINT=Point
Image Structure Metadata:
  COMPRESSION=DEFLATE
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (   78136.546, 5445535.252) (  9d13'43.85"E, 49d 1' 5.25"N)
Lower Left  (   78136.546, 5129395.252) (  9d31'58.92"E, 46d11'14.02"N)
Upper Right (  672716.546, 5445535.252) ( 17d22' 4.91"E, 49d 8'18.04"N)
Lower Right (  672716.546, 5129395.252) ( 17d14'33.24"E, 46d17'46.09"N)
Center      (  375426.546, 5287465.252) ( 13d20'19.28"E, 47d43'42.72"N)
Band 1 Block=29729x1 Type=Float32, ColorInterp=Gray
  NoData Value=-32767
  Unit Type: metre

kann man mit QMS und dem VRT Builder alle Dateien in einer VRT Datei zusammenfassen und diese in QMS laden.

Wie gesagt, im Sommer, bei angenehmen Temperaturen, kann man einem solchen langlebigen Akku schon was abgewinnen. Gut früher hat man halt entweder genügend Eneloop Akkus eingepackt, oder Lithium Batterien, die durchaus 4-5 Tagestouren pro Set durchhalten. Nicht umsonst gibt es speziell für diesen Batterietyp eine Einstellung bei den alten Geräten.

Bei Minusgraden, trennt sich leider die Spreu vom Weizen. Der einzige Batterietyp, der bisher zuverlässig funktioniert hat, sind Lithium Batterien. Frag mich nicht warum das deren Zellchemie mit macht. Es ist einfach die Erfahrung aus zig Wintertouren.

Aber auch klar, wenn ich alle meine Touren zusammen betrachte, sind diese extremen Wintertouren die Ausnahme. Anderseits sind genau bei diesen Wintertouren, die wenigen dabei, bei denen wir ohne GPS wirklich ein Problem gehabt hätten.

Ich schau auf jeden Fall der kommenden Wintersaison mit dem 67er mit gemischten Gefühlen entgegen. Das 64er kommt sicher als Backup mit in den Rucksack.

Ja und dass man im Winter Lithiumbatterien verwenden konnte, die die Kälte besser wegstecken.

Der größte Teil der Kundschaft bleibt wohl bei -10°C zuhause und bevorzugt verbaute Akkus, die sich über USB leicht laden lassen. Im Sommer kann man dem sogar was abgewinnen. Im Winter hat man eine gute Chance im Whiteout ohne Orientierung dazustehen. Ist halt auch so wunderbar "last century".

Ganz schön stolzer Preis, wenn man bedenkt, dass das eTrex mal die low budget Serie war.

Und zudem potthässlich. Können die 80er bitte vorbeikommen und das Teil wieder mitnehmen? Da hat wohl jemand in der Designabteilung bei Garmin zu viele Nostalgie Shorts konsumiert.

Ok, scheint laut Google ein Problem mit dem nativen File Dialog von Ubuntu zu sein. Kann man denn mehrere Dateien mit der Maus auswählen:

* erste Datei mit der linken Maustaste markieren

* Shift Taste gedrückt halten

* letzte Datei mit der Maustaste markieren

Wenn das nicht hilf, kann man den Befehl zum Erstellen der VRT Datei auch in der Kommandozeile ausführen. So wie es hier https://github.com/Maproom/qma…ser-content-gdal-vrt-maps beschrieben wird.

??? Geht es nur mir so, oder versteht jemand anderes was er will?

So ganz verstehe ich die Frage nicht. Vielleicht hilft das Wiki weiter:

DocInstallMapDem

Consumer grade GIS software. Contribute to Maproom/qmapshack development by creating an account on GitHub.

github.com

Das Rumgeeier am Plattkofel hat mir keine Ruhe gelassen, deswegen mal wieder komplett nerdy mit 2 GPS Geräten durch die Alpen gerannt. Beide Geräte an den Tragegurten vom Rucksack. Die Tracks sind im Zip. Auf- und Abstiegsroute sind identisch. Am Hundskopf wurde etwas Fotoshooting im Klettersteig gemacht. Deswegen das hin und her. 64er ist rot. 67 ist blau.

Was fällt auf:

• Das 64er hat die klassischen Pausenknödel. Diese fehlen beim 67. Schon mal gut.
• Dem 64er gehen öfters die "Beine auseinander". Sprich die Aufstiegsroute weicht deutlich von der Abstriegsroute ab. Nahe am Felsen (Hundskopf) hat hier aber auch das 67er so seine Probleme.
• Nach der Rast auf der Sonnenterasse der Hütte (also guter Empfang) irrlichtert das 67er kurzzeitig beim Abstieg.

Also Licht und Schatten. Sieht so aus, als ob die Nachbearbeitung beim 67er wirklich so ihre Probleme hat.

Das Höhenprofil vom 64er (DEM Daten in rot)

Und das vom 67er

Beide Geräte sind mit Autokalibration losgelaufen. Das 67er ist mehr aus dem Ruder gelaufen. Außerdem ist das 67er mit 1783m deutlich unter den offiziellen 1807m des Gipfels geblieben. Das 64er mit 1805 liegt nahezu perfekt. Die zu geringe Höhe ist mir auch schon bei anderen Touren aufgefallen.

Für einen modernen Empfänger, von dem man sich eine Verbesserung verspricht, ein doch sehr durchwachsenes Ergebnis.

Die neuen Geräte haben ja alle Empfänger die NavStar und Galileo Satelliten zugleich verarbeiten können und außerdem auch Multiband unterstützen. Anstatt der jahrelang gewohnten 3m Genauigkeit wird einem jetzt 1.8m angezeigt. Also alles besser!...?

Nach den ersten Touren in anspruchsvollem Gelände habe ich da inzwischen meine Zweifel. Seit Jahren bin ich mal wieder auf dem Plattkofel gewesen. Leider hatte ich nur das 67er dabei und nicht auch noch das 64er. Aber es gibt einen alten Track von 2019. Und natürlich davon auch die originale Aufzeichnung ohne Nachbearbeitung.

Das ist zum Vergleichen nicht ideal, weil die Satellitenkonstellationen natürlich unterschiedlich waren. Andererseits geht es bei der Tour oft an Felswänden vorbei. Auf den Gipfel sogar in einer Rinne. Es sind also starke Fehler durch Reflexionen und mangelnde Satellitenauswahl zu erwarten. Man kann aber auch erwarten, dass der Empfänger sehr schnell wieder auf die richtige Position springt, wenn die Bedingungen besser werden. Naja, könnte man.

Hier die Tour mit beiden Tracks. Rot ist der Track vom 64er, blau der vom 67er. Das Höhenprofil ist vom 64. Man sieht deutlich wo die Position gewandert ist, weil die Höhendaten aus den DEM Daten gelesen natürlich für diese falschen Positionen ergeben. Im falsch positionierten Trackpunkt ist natürlich die richtige gemessene Höhe abgespeichert. Dadurch kann man sehr gut die Problemstellen identifizieren.

Diese liegen beim 64er im Weg von der Demetzhütte zur Langkofelhütte. Den Aufstieg zum Plattkofel hat das Gerät eigentlich sehr gut aufgezeichnet, wenn man die topographischen Bedingungen bedenkt.

Und jetzt state-of-the-art das 67er. Da sieht man, dass in dem Moment wo das Gelände für den Empfänger anspruchsvoll wurde, das Gerät komplett die Orientierung verloren hat. Erschreckend ist hier, dass sogar auf dem Gipfel, wo wirklich guter Empfang ist, das 67er weiter geirrlichtert ist. Erst beim Abstieg hat es sich wieder gefangen. Technik die begeistert

Hier nochmal die Stelle im Detail

Für mich sieht es so aus als ob die Nachbearbeitung (Kalmanfilter, etc) noch ein echtes Problem hat und bei schlechtem Empfang komplett versagt. Deprimierend, dass Garmin es immer wieder schafft, mit jeder neuen GPS Chipsatzgeneration die Sache zu verschlechtern.

Zitat von ConiKost

Nicht nur dort. Auch in Deutschland beim Motorradfahren. Vor uns war dieses Jahr ein Motorradfahrer in die Leitplanke geknallt. Das Notrufsystem der GS und via Smartphone konnte nichts auslösen, weil schlicht an der Stelle es keinen Mobilempfang gab (Weder D1, D2 noch E-Plus/O2). Musste dann per inReach mit meinem Montana den Notruf auslösen.

Was wiederum ein Armutszeugnis für die deutsche Infrastruktur ist. Wobei man auf der Straße noch einfacher schnell in einen Bereich mit Netz kommt. Aber ja, wenn es dumm läuft, sind das die paar Minuten die fehlen.