Beiträge von kiozen

Zitat von Lumi

Nur weil das immer so dargestellt wird als ob die Menschheit ohne Ki nicht weiter existieren kann auf dem Planeten.

Man darf nicht alles glauben was im Internet steht

Zitat von Lumi

Und das im Ki Zeitalter.

Glaubt wirklich ernsthaft jemand daran, dass KI Software für ein embedded Gerät schreiben kann? Oder wirklich jede x-beliebige komplexe Software? Das ist naiv.

KI kann sehr gut Softwareschnipsel für Standardprobleme erstellen. Auch komplexe Programme, die man leicht mit modularen Softwarebausteinen erstellen kann, sind machbar.

Von laufzeit- und speicheroptimierter Software auf einer komplett individuellen Hardwareplattform ist man noch weit entfernt. Zumal man einen nicht unerheblichen Aufwand betreiben müsste genau zu definieren was man will und wie das zusammenpasst. Und daran scheitert es ja schon heute bei normaler Entwicklung.

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.