Beiträge von kiozen

Also die reine Geätefirmware lässt sich bei den Geräten ja noch flashen, wenn man die Firmwaredatei auf dem Gerät in den Garmin Ordner legt. Dann wird die beim nächsten Start installiert. So musste man das auf Linux jahrelang machen.

Die einzelnen Firmwaredateien gab es auch irgendwo im Netz inklusive Anleitung. Google ist dein Freund.

Die Sache birgt wie immer ein gewisses Risiko. Wenn es jetzt nicht wirklich einen Bug gibt der relevant ist und man sicher weiß dass der in einer neueren Firmware gefixed ist, würde ich mir persönlich die Mühe nicht machen.

Ich glaube unser Workflow ist nicht so unterschiedlich. Ich habe zwar alles in einer Datenbank, aber das ist eher Nebensache.

Wie schon erwähnt habe ich in dieser Datenbank auch die Tracks und Wegpunkte der Rother Wanderführer. Das sind pro Buch ~50 Tracks und etliche hundert Wegpunkte. Wenn ich jetzt in einem dieser Gebiete was plane, wird solch ein Ordner in den Arbeitsplatz geladen.

Dann erstelle ich einen Planungsordner. In der Regel ist das ein GPX Ordner, weil ich später eh die Planung an andere Leute schicken muss. QMB Format geht natürlich auch. Da bleibt die Änderungshistorie erhalten. Kann nur niemand außerhalb von QMapSack was anfangen.

In diesem Planungsordner wird nun kopiert was nötig ist. Und dann wird der Datenbankordner unsichtbar gemacht oder aus dem Arbeitsplatz entfernt. Bei mir sieht der Arbeitsplatz immer sehr übersichtlich aus, weil ich da nicht so viel haben will. Lenkt nur ab.

Kleinere Seitenprojekte werden auch gerne in weiteren Projekten (GPX Datei) abgelegt. Und bei Bedarf in das das Hauptprojekt kopiert.

Die Planung selber speichere ich nur sehr selten in der Datenbank. In der Regel dann, wenn ich das Projekt nicht realisieren konnte und es für wann anders halten will. In der traurigen Ecke der nicht gemachten Touren.

Nach der Tour werden die Aufzeichnungen ausgewertet, bereinigt und dokumentiert. Das geht in einen Datenbankordner.

In der Datenbank lösche ich nur was, wenn ich wirklich Mist abgespeichert habe. Bzw wenn ich eine ganze Sammlung über Bord werfe. Das sind dann in der Regel ganze Ordner, sehr selten einzelne Sachen.

Ich glaube für die meisten User stellt sich das Problem nicht. Wenn ich lese dass zwischen hunderten von Tracks gesucht werden muss, frage ich mich warum hunderte von Tracks in einem Ordner liegen. Kann man so machen, aber dann ist es eher ....

Projektordner in meiner Datenbank haben in der Regel eine handvoll Tracks. Die einzigen Projektordner mit ~50 Tracks sind Tracksammlungen von Rother Wanderführern. Und da möchte ich eigentlich nichts löschen.

Überhaupt lösche ich aus der Datenbank nur sehr selten etwas. Das Zeug landet in der Datenbank, weil ich es auf ewig halten möchte.

Wenn ich doch mal größere Mengen an Daten aussortieren will, dann lade ich die in einem Projekt (egal woher) erstelle mir neue Projekte, auf die ich jetzt ausgewählte Daten verteile. Und danach wird der ganze Bums gespeichert und geschlossen (aka F8 drücken). Danach kann ich immer noch entscheiden ob der große Quellordner gelöscht wird oder nicht.

"Beim Anklicken eines Objekts sowohl den Arbeitsplatz- als auch den Datenbankeintrag markieren."

Das ist nicht so einfach. Die Datenbank kann sehr große werden. Den gesamten Baum in die Ansicht laden dauert dann ewig. SQLite mit Qt ist da nicht besonders performant. Wenn das Projekt nicht schon mal in der Datenbankansicht offen war, dann wird da nichts gefunden. Es müsste erst sehr aufwändig der Jeweilige Pfad on-the-fly geladen werden.

"Oder zwei getrennte Funktionen anbieten: „Aus Arbeitsplatz entfernen“ und „Aus Datenbank löschen“.

Wäre wahrscheinlich eher möglich. Nur ist auch das schon irreführend. Der Eintrag müsste exakt lauten "Element aus diesem Ordner in der Datenbank entfernen". Und diesen Dualismus für Datenbankprojekte müsste man durch das ganze GUI ziehen. z.B Bei Mehrfachauswahl zwischen Datenbankprojekten und GPX Projekten wird es dann noch wilder.

"Oder beim Entfernen eine kurze Rückfrage stellen, welche Aktion gewünscht ist."

Ich glaube QMapShack hat eh schon genügend lästige Rückfragedialoge. Die Erfahrung zeigt: Noch mehr davon nerven und verwirren. Also bei mir wäre zu 99% diese Frage überflüssig, weil ich nur etwas im Arbeitsplatz lösche.

Ich denke die Vorgehensweise, bei großen Mengen den interessanten Part in ein neues Projekt zu kopieren, hat sich eigentlich bewährt.

Vielleicht noch zum Hintergrund: Das Thema ist ja nicht neu. Die Vorschläge auch nicht. Ausprobiert habe ich schon vieles. Ein paar Sachen waren gut, haben den Code nur bedingt komplexer gemacht. Der Rest ist entweder gescheitert, weil es einfach nicht geht, oder weil es zu komplex wurde.

Wenn du auf dem Arbeitsplatz etwas aus einem Projekt löscht, ist nicht klar, ob du es wirklich in der Datenbank löschen willst oder ob du es einfach nur aus dem Arbeitsplatz entfernst, weil du es gerade nicht sehen willst. In einem solchen ambivalenten Fall ist die klare UI Regel den weniger destruktiven Weg zu nehmen.

Und wenn Du etwas zu einem Datenbankprojekt im Arbeitsplatz hinzufügst, dann wird das natürlich erst in die Datenbank geschrieben, wenn Du das Projekt speicherst.

Die meisten Leute haben damit Probleme, weil die Situation vom üblichen "Datei auf der Festplatte und offen in einem Editor" abweicht. Im Falle einer Datenbank hast Du 2 Ansichten auf die Datei offen. Einmal die Ansicht der kompletten Datenbank und dann die Ansicht nur eines Teils (Arbeitsplatz). Und genau dieser Aspekt bringt einen neuen Freiheitsgrad in die Sache, den man erst mal begreifen und lernen muss.

Es gibt aber auch genügen Benutzer die die Datenbank nicht verwenden und das DockWidget ausgeblendet haben. Also klassisch nur über Dateien arbeiten. Geht auch. QMapShack drückt einem die Datenbank nicht zwingend aufs Auge.

Zitat von asp_52

Vielen Dank AsterixDerGallier!

Ich hatte überall QMapShack Vollbild gesucht und nicht kapiert, dass es LinuxMint sein musste

QMapShack hält sich einfach nur an die normale Gepflogenheit dass mit F11 Vollbild umgeschaltet wird. Das hat eigentlich mit Mint oder dem OS nichts zu tun.

Was mich wundert: Wenn man im Vollbild ist und QMapShack abwürgt (kill oder PC ausschalten) dann startet es das nächste Mal wieder ganz normal.

Strange. In the plist I see multiple IMG maps activated. However in the debug log 1 there is only one IMG map activated.

Session is closed properly, so the plist file should be written.

I do not know Macs, but can you make sure access rights are ok?

Maybe deleting the plist file gives another clue.

"/Users/e-jvanderlinden/Library/Preferences/org.qlandkarte.QMapShack.plist"

This is the file with the configuration. It should list your maps and their state of activation. Can you post it after you setup your maps and closed QMapShack

Does QMapShack terminate properly? Or with a crash?

Still the debug output would help. Currently it's glass globe guessing.

If I understand you correctly:

* Maps, DEM, and other setup is stored correctly into the config file. And everything is restored on a restart.

* Your workspace (projects, waypoints, tracks, etc) is not restored on a restart. However you see that the workspace.db is written.

If workspace.de is not restored I would expect at least some sql warnings in the debug output. Start qmapshack with "-d" option and post the output.

Zitat von ejvanderlinden

If I change this with the -c commandline option it still does not work and I see no files are stored in this folder.

/Applications/QMapShack.app/Contents/MacOS/QMapShack -c /Users/e-jvanderlinden/Documents/QMapShack/Config/

/Applications/QMapShack.app/Contents/MacOS/QMapShack -c /Users/e-jvanderlinden/Documents/QMapShack/Config/QMapSahack.conf

And make sure the path /Users/e-jvanderlinden/Documents/QMapShack/Config/ is existing and is writable.

Ja Handgeräte sind Nische. Wenn man es genau nimmt, brauchen die meisten Menschen keines. Also im Sinne von: Hier gibt es keine vernünftige Alternative zu einem handheld Outdoor GPS.

In der Regel reicht heute ein Smartphone für Wanderungen in einem definierten Wegenetz. So ein Garmin ist gut für Expeditionen über mehrere Tage ohne Lademöglichkeit. Und natürlich im absoluten Sauwetter. Vor allem im Winter.

Einziger allgemeiner Nutzen: Zuverlässige Trackaufzeichnung.

Das die Geräte beim Kunden reifen ist nichts Neues. Die Software bekommt Garmin in der Regel auf einen akzeptablen Stand. Bei ganz neuer Hardware ist aber immer das Risiko von nicht wirklich fixbaren Problemen vorhanden. Das 62er und 64er waren bis zum Ende rechte Krücken. Das 62er noch mehr als das 64er.

Und beim 67er ist die Auto-Kalibration bei der Höhe und die Berechnung der Höhenmeter eine echte Regression. Scheint aber Niemanden zu stören. Wird nicht gefixed.

Aber ich denke auch ,das 67er wäre aktuell noch die beste Alternative. Sofern man noch eines bekommt.

Mein Rat wäre: Schaue auch das H1 beim Händler an. Es ist größer, schwerer und hat ein komplett anderes Bedienkonzept. Das klingt bei den Reviews alles ganz interessant. Aber am Ende musst Du damit klarkommen. Und das kann keiner für Dich entscheiden.

In Reach: Kostet halt. Ob man das im Mittelgebirge wirklich braucht? Ich würde mich an deiner Stelle fragen: Bin ich oft alleine im wenig begangenem, schwierigem Gelände unterwegs? Mache ich Touren, bei denen ein reales Risiko besteht, z.B. Wintertouren im alpinen, lawinengefährdetem Gelände.

In Reach kann Hilfe rufen, wenn sonst niemand da ist. Und Hilfe kann schneller kommen, weil man nicht Empfang suchen muss. Da ist bei vielen Unternehmungen aber nicht wirklich entscheidend, zumal das Risiko gering ist. Sprich Schaden multipliziert mit Wahrscheinlichkeit = Risiko. Und deine Entscheidung ob dir das Risiko die Kosten wert ist.

I brought it to the attention of the Windows package maintainer.

Btw: Each release has a discussion thread in github: https://github.com/Maproom/qmapshack/discussions/1103 This is the direct way to address issues like that.

Und wenn man sehr große Tiff Dateien hat, mit gdalinfo testen, ob diese Kacheln verweden. Wenn nicht, dann kann man mit GDAL die Datei umwandeln damit sie intern 1024x1024 Kacheln verwendet. Das macht den Zugriff etwas effizienter.

GeoTiff wäre ideal, da in diesem Format schon alles drinnen ist.

die jp2 sind wahrscheinlich die eigentlichen Kartendateien in JPEG2000 Format. Dieses Format macht die Sache kompliziert. GDAL kann zwar damit umgehen, benötigt aber prioritäre Bibliotheken. Diese sind sogar für Privatpersonen kostenlos, du musst dich aber vorher registrieren und dabei wie üblich deinen Erstgeborenen, etc versprechen.

UTM ist eine Transversal Mercator Projektion. Diese hat den Vorteil, dass die horizontale Verzerrung gering bleibt. Der Nachteil: Das gilt immer nur für eine Zone. Wenn die Karte mehrere Zonen überspannt, braucht man eine *.vrt Datei pro Zone. Oder man projiziere alles auf eine Zone, dann ist aber der Vorteil weg. Oder man projiziere alles auf Mercator. Dann ist zwar auch alles verzerrt, aber man muss sich über keine Zone Gedanken machen.

Wenn man in dem ganzen Zeugs nicht besonders fit ist, würde ich empfehlen massiv auf die Hilfe von KI zu setzen. Wenn die lokal zugreifen kann, dann kann die mit Python und GDAL wahre Wunder bewirken

Das hängt so ein wenig davon ab was diese Sentinel2 Daten sind. Ich vermute mal irgendein Bildformat. Welches? Und wie sind diese Dateien referenziert? Also welche Projektion, welches geodätische Datum? Gibt es Referenzkoordinaten?

Fragen über Fragen. Etwas mehr Info würde nicht schaden.

Aber das Ziel ist immer klar:

* Mit GDAL eine oder mehrere georeferenzierte Bilddatei(en) schaffen

* Mit GDAL oder auch QMapShack diese Datei(en) mit einer *.vrt Datei erfassen

* die *.vrt Datei wird von QMapShack erkannt und kann angezeigt werden.

HereWeGo ist cool. Verwende ich auch gerne.

Ist halt der Git Hash vom Softwarestand noch dabei. Damit kann der Entwickler dann feststellen, welcher Softwarestand das genau ist. Spricht aber nicht unbedingt für den Release Prozess bei Garmin.

Die Freizeitkarte einfach auf die SD Karte kopieren.

Datenaustausch:

Das Gerät sollte sich ja immer als USB Speicher in deinem System ansprechen lassen. Damit kannst Du immer GPX Dateien auf dem Gerät abspeichern. Ich empfehle in diesem Fall immer die Option, sie als GPX 1.1 abzuspeichern, weil dann keine Erweiterungen verwendet werden, die für das Gerät zum Problem werden könnten.

In wie weit beim Mac die Geräteerkennung noch funktioniert, kann ich nicht sagen. Bisher keine Klagen gehört. Das muss aber nichts bedeuten. Einfach mal anstecken und warten ob das Gerät im Arbeitsplatz von QMapShack aufgelistet wird.

Wenn die Geräteerkennung geht, dann einfach für einen Projektordner das Kontextmenü aufrufen und "Ans Gerät senden" auswählen. Dann legt QMapShack eine GPX Datei auf dem Gerät an, mit em Namen das Ordners und den Daten in diesem Ordner.

Hier ist auch die Dokumentation im Wiki:

DocGisDevices

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

github.com

Wie schon gesagt, wer sich im Gamin Vendor Lock-in bequem eingerichtet hat, für den wird es hart, wenn er dieses verlässt. Das ist auch komplett unabhängig von QMapShack.

Garmin schafft proprietäre Lösungen mit geschlossenen Formaten. Ein wunderschönes Beispiel sind die Routen, die mit Bravour ein geschossenes Format in einem offenen Format implementieren. Auf diese Art und Weise kann keine andere Software jemals Routen so implementieren, dass sie für Garmin Geräte optimal funktionieren. Nur dumm, wenn dann Garmin keinen Bock mehr hat die Software weiter zu pflegen.

Da gibt es nur 2 Lösungen:

1. Kompromisslos die Garmin Software weiter am Leben zu erhalten. Mit dem dementsprechenden Aufwand.

2. Kompromisse eingehen - und ja die tun weh - und sich nach einer anderen Software umsehen.

Wenn ich die letzten Jahrzehnte Revue passieren lasse, dann war MapSource und Basecamp auch für fast jeden ein K(r)ampf. Das Naviboard spricht Bände. Wenn ich mir die ellenlangen Threads des letzten Jahres ansehe, wie sich ausgetauscht wird, wie man dies und jenes irgendwie in Basecamp der Mapsource bewerkstelligt, dann ist das nicht einfacher. Es haben sich nur genügend Leute reingefuchst.

Und um es auch nochmal klarzustellen: QMapShack ist nie als Basecamp oder Mapsource Clone entwickelt worden. Im Gegenteil. Deswegen glaube ich auch nicht dass es pauschal für jeden das ideale Programm ist. Vor allem nicht wenn man einen Clone für Basecamp und Mapsource sucht.

Ich verwende zum Beispiel überhaupt keine Gamin Karte mehr in QMapShack. Maximal noch im Gerät für die Gegenden, für die ich nichts Besseres habe. Brauche ich Navigation, wird das über eine App erledigt. Brauche ich Orientierung im Gelände, ist es ein geplanter Track auf dem Garmin. Hier ist auch viel wichtiger gute Topokarten auf dem Gerät zu haben. Am besten die, die ich auch als Papierkarte in der Hand halte. Und auch bei den Höhendaten habe ich lieber die 1x1m Version, als die grob auflösende aus der Garminkarte.

Und genau dafür brauche ich QMapShack. Insofern hat das Hubert absolut richtig erkannt: Wer etwas mehr Anspruch an das Kartenmaterial hat, findet wahrscheinlich eher Gefallen an QMapShack. Wer gerne Routen planen will und diese 1:1 auf seinem Garmin verwenden will, kommt um die Garmin Software nicht herum.