Beiträge von kiozen

Zeigt Basecamp den Proximity-Radius eines Wegpunktes an?

Für alle Sammler, Jäger und Freunde der Kommandozeile:

Mit dem Tool aria2c kann man recht komfortabel einen ganzen Dateisatz herunterladen. Dazu gibt es auf den Seiten zu den Karten weiter unten immer einen Abschnitt "Komplettdatensatz" mit einem Metalink. Den kann man mit aria2c verwenden. z.B. für die DOK10 Karte

aria2c https://geodaten.bayern.de/odd/a/dtk/k/dok/meta/metalink/09.meta4

Damit landen alle Dateien in dem aktuellen Ordner. Mit `-d` kann man einen alternativen Pfad für die Dateien angeben.

Mit den GDAL Tools kann man die einzelnen Dateien sehr schnell zu einer virtuellen Komplettkarte zusammenfassen:

gdalbuildvrt Bayern_DOK10.vrt <path_to_files>/*.tif

Da die Karte monströs groß ist, tun sich die Programme schwer, die Karte für ein größeres Gebiet anzuzeigen. Ok, das macht bei Rasterkarten auch wenig Sinn weil nur noch Pixelbrei zu sehen ist. Dennoch helfen in einem gewissen Bereich Übersichtsebenen:

gdaladdo --config COMPRESS_OVERVIEW LZW Bayern_DOK10.vrt  8 16 32 64

Die Zahlen am Ende sind die Skalierungsfaktoren für die Ebenen. Kann man evtl noch optimieren. Es entsteht eine Datei Bayern_DOK10.vrt.ovr die immer neben Bayern_DOK10.vrt liegen muss.

Bei den Höhendaten machen Übersichtsebenen keinen Sinn.

Gibt es wahrscheinlich schon seit einiger Zeit, mir ist es nur jetzt aufgefallen:

https://geodaten.bayern.de/opengeodata/index.html

Die wahrscheinlich spannendsten Datensätze sind

Digitale Ortskarte 1:10.000

Digitales Geländemodell 1m

Digitales Orthophoto 40cm

Für alle die sich über diesen Post wundern: Bayern hat sich die vergangenen Jahre nicht gerade hervorgehoben diese Daten öffentlich zugängig zu machen. Um so erfreulicher, dass das jetzt passiert.

Gut möglich, dass irgendwas nicht so ankommt wie erwartet. Siehe z.B. https://github.com/Maproom/qmapshack/issues/570.

Der ganze Realtime Support ist damals als POC geschrieben worden, um zu zeigen was geht. Wenn das jemand wirklich braucht und verwenden will, muss der Code deutlich verbessert werden. Und dazu war es bisher niemandem wichtig genug.

Der ganze Code zum dekodieren ist in CRtGpsTetherInfo.cpp Am besten mal ein paar Debug Messages setzen. Dann findet man recht schnell heraus, woran es hakt.

Auch schöne Grüße

Das mit dem Mitgliederschwund ist meiner Meinung nach ganz normal. Zum einen sind Foren ein veraltetes Kommunikationsmittel, das von den Jüngeren überhaupt nicht verwendet wird. Zum anderen ist das Navi als Einzelgerät einfach nur noch ein Nischenprodukt. Viele verwenden einfach ihr Smartphone und denken nicht länger darüber nach. Hilfe holt man sich bei Freunden und Bekannten.

Und dieses Basteln und Herumfrickeln ist doch auch nicht mehr wirklich nötig. Der Zugang zu Karten und Navigation ist heute einfach. Über die Qualität, Zuverlässigkeit und den Datenschutz kann man zwar diskutieren, den meisten Benutzern ist das aber schuppe.

Was wirklich auffällt ist das Fehlen von Spam. Jetzt wo Du es erwähnst.... Vielen Dank dafür!

Schöne Feiertage!

Warum es dennoch sinnvoll ist POI Daten in einem anderen Format als GPX anzubieten:

• GPX ist ein textbasiertes Datenformat und damit sehr ineffizient, um Sammlungen von 10.000+ POIs anzubieten.
• Die Spezifikation von GPX ist einfach zu rudimentär, um Zusatzinformationen zu POIs vernünftig abzulegen. Jeder Versuch das über die Erweiterungsfelder zu machen, verwandelt das Format in einen proprietären Sumpf und führt den eigentlichen Gedanken von GPX ad absurdum.
• GPX ist keine Datenbank. Eine effiziente Suche oder Verwaltung ist damit nicht möglich.

Das bedeutet nicht, dass mit Datenbankformaten alle diese Probleme komplett zu lösen sind. Wenn es sich jedoch um ein bekanntes Format wie z.B SQLite handelt, ist dieses offen genug, um Code zu schreiben, der mit den Daten arbeiten kann.

Hardware ist halt vergleichsweise billig und lässt sich schnell versenden.

Softwarebugs können nur gemeldet werden, dann müssen sie verifiziert werden und dann priorisiert. Alleine dafür können schon ein paar Wochen ins Land gehen - wenn es gut läuft. Und je nach Priorisierung wird ein Bug gefixed, oder nicht. Die Entwicklungsabteilung kostet laufend Geld, deswegen versucht man die personell klein zu halten. Und idealerweise entwickeln die neue Produkte, die wieder Geld einbringen. Bugs fixen ist da nur Sand im Getriebe.

Wenn man das mal bedenkt, dann läuft die Software bei Garmin ganz ok. Wirklich kritische Bugs werden schnell gefixed. Der Rest eher nicht. Dafür ist das Produkt vergleichsweise billig und kostet nur einmal.

NiMH-Akkus sind auch sehr kälteanfällig. Aus der Erfahrung heraus sind bisher Lithium Batterien die zuverlässigste Quelle im Winter. Wenn man qualitativ gute kauft, kommt man mit 1-2 Sätzen durch den Winter. Ich denke das ist vertretbar.

Advertise: für andere sichtbar sein und seine Funktionen darstellen/anbieten

Discovery: andere Geräte finden und deren Funktionen herausfinden.

Ich glaube da kann keiner einen fundierten praktischen Test vorlegen.

Grundsätzlich muss man irgendwie für sich definieren, welche Lebenszeit man von einem GPS erwartet. Wenn ich mir so einige aktuelle Beiträge zum 60SCx durchlese, scheint für einige 10-20 Jahre normal zu sein. Das macht ein Li-Ion-Akku eher nicht mit.

Wenn man sagt alles über 4-5 Jahre ist ok, dann denke ich, hält ein guter Akku das aus. Zumal man das Gerät, verglichen zu einem Smartphone, nicht 24/7 verwendet. Und damit ist die Anzahl der benötigten Ladezyklen deutlich reduziert.

Wenn man dann noch den Akku nett behandelt - also nicht tief entladen, nicht bei 100% Ladung länger lagern, etc - dann sollte die Akkulebensdauer eher zweitrangig sein. Vorher gehen bei Gamin die Gummis und Verklebungen kaputt.

Was aus meiner Sicht eher gegen das Konzept spricht, ist die Kälteanfälligkeit des Akkus. Mein Aventura2018 macht bei -10°C sehr schnell die Grätsche. Das hat explizit einen Lipo Akku verbaut. Bei Garmin steht Li-Ion drauf (was ein Lipo sein kann, aber nicht muss). Könnte somit ein wenig besser sein. Wunder würde ich nicht erwarten. Hier sind halt Gerät mit einer normalen AA Halterung besser. Dort kann man im Winter Lithium Batterien verwenden, die im Gegensatz zu den Akkus deutlich unempfindlicher gegen Kälte sind.

Garmin wird den Akku garantiert nicht austauschen. Innerhalb der Garantiezeit werden sie dir ein neues Gerät geben. Danach, wenn Du Glück hast, ein moderneres Gerät zu einem schwach reduzierten Preis.

Zu wechseln ist der Akku:

https://www.outdoorkompetenz.c…psmap-66sr-akku-wechseln/

Mein Problem bei solchen Stunts ist immer: Ich habe noch nie einen Akku nachkaufen können, der die selbe Kapazität hat, wie der original verbaute. Die haben zwar die selben Daten aufgedruckt, qualitativ sind die aber immer eher Ausschussware.

Meines Wissens schreibt der Bluetooth Standard keine Symbole für die einzelnen Verbindungsphasen vor. Schöner wäre wahrscheinlich ein animiertes Symbol. So etwas müsste aber erst mal vom System unterstützt werden.

"Werbe- und Entdeckungsmodus" herrlich wenn man das brav vom Englischen ins Deutsche übersetzt. Aber cool, dass eine Antwort kam. Das hier während dem Verbindungsaufbau tatsächlich ein anderes Symbol angezeigt wird hätte ich nicht vermutet. Macht aber Sinn und ist löblich.

Es liest entweder diese Datei und nimmt die Pfade, oder es ignoriert sie. Da es sich um eine Datei auf der SD Karte handelt, kann man diese auch einfach entfernen.

Vielleicht braucht es auf der SD Karte eine GarminDevice.xml? Die definiert wo die Firmware die 7 Tassen im Schrank erwartet. Müsste man ohne Probleme vom internen Speicher auf die SD Karte kopieren können. Vielleicht einen Versuch wert.

Der Markt für Karten und Navigationslösungen steht unter Druck und TomTom ist einer der kleineren Mitstreiter. Klar versuchen die Kosten zu sparen.

Ich denke nicht, dass es viele Kunden gibt, die es toll finden, wenn ein Produkt mehr kostet, weil hirntote Aufgaben, die einfach von einer Software erledigt werden können, von Arbeitern im unteren Lohnsektor erledigt werden.

Das ist nicht TomTom, das sind wir.

Das ist zwar schon gefixed aber noch nicht in einem Release.

Ok. Interessant und gut zu wissen.

Das mit den Short Path ist ein übler Windows Hack, der in einer Software die Cross Plattform compiliert wird nichts verloren hat.

Letzten Endes muss das über die Boardmittel von Qt gelöst werden, was sicherlich auch möglich ist.

hm, ok. Da müsste der Pfad vorher noch in einen gültigen URL umgewandelt werden wenn der Link gesetzt wird. Mal sehen ob dafür irgendwann Zeit finde.

ich glaube mit einem "%20" sollte man das Leerzeichen ersetzen können. Müsste ich aber jetzt selber nachsehen wie das genau geht.