Beiträge von kiozen

Und was mir auch auffällt: "Multi-Cache" ist "Multi-cache". Ist das jetzt die offizielle Schreibweise? Oder nur temporär?

Edit: Laut KI scheint das jetzt so zu sein.

Fehler gefunden. Aber das sieht mit den ganzen Virtual Stages ja echt bescheiden aus.

Gibt es für die "Virtual Stage" ein offizielles Symbol? Am besten als SVG.

Das sollte natürlich nicht so sein. Da muss bei den massiven Änderungen in den letzte Versionen ein Bug reingekrabbelt sein. Das Dumme ist nur, dass ich nichts mehr mit Geocaching zu tun hab und den Kontrollfreaks von Geocaching.com schon lange den Rücken gekehrt habe. Also auch kein aktuelles GPX mit Caches habe. Sprich ich kann es zum Debuggen nicht nachstellen.

Zitat von WST

Wohin kann ich mich wenden oder wen darf ich kontaktieren, damit hier auch die 1.19.0 erscheint? Ich bin noch nicht firm mit Linux/Kubuntu.

Der Maintainer der Debian Pakete bekommt jedes Release mit. Bis jedoch bei Debian Stable die aktuelle Versionen einfließt dauert es lange. Sprich es wird sich hier nichts tun solange deine Distro auf ein stabiles Debian aufsetzt. Da hilft auch drängeln nicht.

Es gibt natürlich auch den instabilen Zweig von Debian, dort ist die neueste Version zu haben

Debian -- Ergebnisse der Paketsuche -- qmapshack

Aber dass ist nur was für die Leute die wissen was sie tun.

Deswegen gibt es AppImages.

Zu dem was in den ersten Beiträgen schon gesagt wurde noch ein Hinweis. Garmin hat immer schon ein Gummiproblem. UV Licht, Schweiß, Sonnencreme setzen der Gummierung zu. Weichmacher entweicht über die Jahre. Klebstoff versagt. Deswegen beim Gebrauchtkauf darauf achten in welchem Zustand die Gummierung ist. Ist das Gerät selten verwendet worden, solle es ok sein.

Alle Geräte der neueren Generationen mit USB Massenspeicher oder MTP Unterstützung sollten technisch vollkommen ausreichend sein. Das eTrex35 ist vor 10 Jahren herausgekommen. Technisch ok, aber beim Gummi bitte genau hinsehen und es mal in die Hand nehmen. Wenn es 10 Jahre in der Schublade lag, sollte noch genug Leben in der Gummierung stecken.

Nur mal so zum Vergleich: mein GPSMap64 (8 Jahre alt) hat in diesem Jahr die Blasenkrankheit bekommen. Sprich der Gummi löst sich vom Gehäuse und damit wird es undicht. Eigentlich schade, weil technisch noch vollkommen in Ordnung und soweit auch ausreichend. Gut, das Gerät hat aber auch einiges an "Erfahrung" auf dem Buckel.

Der stürzt im QtWebEngineCore ab. und zwar so ziemlich direkt ohne dass der Code von QMapShack involviert ist.

Das QtWebEngine Module ist ein Zusatzmodul zu Qt. Bitte sicherstellen, dass es auch die selbe Version wie der Rest hat.

Wobei der Absturz bei SetGpuInfo() stattfindet. Das kann auch ein Problem mit Wayland sein. Meiner Erfahrung nach ist sich Qt und Wayland noch nicht 100% grün. Vielleicht mal auf X11 umschalten.

TroubleShooting

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

github.com

Zuerst einmal mehr Info als "es geht nicht" liefern .

Ins Blaue geraten: mehrere Installationen von QMapshack auf dem System.

Es ist eine 1.19.0 geworden

Zitat von wthaemelt

(kiozen muss vielleicht noch überlegen, was auf 18 als nächste Zahl kommt)

Ich sehe es erst jetzt Es kommt natürlich die 42

Und meine Vespa hat keinen Vergaser mehr.

Wann Wolfgang Zeit und die Nerven für eine neue Windowsversion hat kann ich nicht sagen.

Aber Version 1.9.0 kommt bald. Und ich denke es lohnt sich darauf zu warten.

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.