Beiträge von kiozen
Garmin fenix 7X und epix Gen 2 im Test
-
-
Ich glaube aber auch nicht, dass nur die absoluten Laien in den Bergen unter Lawinen begraben werden, weil die da aus gesundem Repekt nicht hochgehen würden.
Gefährdeter sind tatsächlich die Leute, bei denen sich der Ehrgeiz eine Tour zu gehen, über eine kritische Einschätzung der Lage hinwegsetzt.
Aber es gibt auch genügend Stellen, wo die Leute recht blauäugig die Sache angehen. Ein Tal weiter geht es aufs Kreuzjoch. Bis zur Hütte überhaupt kein Problem und beliebt bei Familien. Zum Joch hoch sind es nochmal 300 Höhenmeter. Man sieht das Joch von der Hütte. Da gehen einige gerne noch mal weiter. Am Joch selber hing, als wir da waren, eine dicke Wechte. Und auf dem Joch sah man schon eine dünne, unauffällige Spalte. Das Teil wird wohl demnächst abgehen. Wer das nicht sieht, geht womöglich auf der falschen Seite der Spalte, und löst die Wechte aus. Und die meisten Leute gehen den Hang unterhalb der Wechte hoch. Ich möchte nicht wissen wie viele Leute dabei einfach nur Glück haben. Erfahrung werden nicht so viele haben. Einen Lawinenpieps wahrscheinlich noch weniger.
Wenn ich dann auf Jahre alten Karten solche imaginäre "Winterwege" sehe, hätte ich da meine Zweifel, ob das wohl zuverlässig ist.Du hast es nicht verstanden. Das ist kein Weg, dem man sklavisch folgt. Sondern ein Hinweis wo man mit der geringsten Gefährdung hoch oder runter kommt. Und solange sich der Berg nicht grundlegend verändert, behält diese Empfehlung ihre Gültigkeit. Das heißt noch lange nicht, dass dort alles sicher ist. Gerade durch Wind ändert sich die Gefahrenlage ständig. Das muss erkannt werden und die Tour angepasst werden.
-
Gutes Beipiel für die Limiten der Karten, danke kiozen!
Ich bin eigentlich etwas über die Detailarmut der Tobacco erstaunt, habe nie eine in den Fingern gehabt, aber immer sehr gutes gehört. Ist sie grösser als 1:50'000? Oder liegt das einfach am reinzoomen?Die Karte ist 1:25000 und nicht mit den exzellenten Schweizer Topokarten zu vergleichen. Das ist dann nochmal eine ganz andere Kategorie. Gescannt wurde die Karte mit 400dpi. Auf der Papierkarte ist der Ausschnitt deutlich kleiner. Er deckt ungefähr 1km^2 ab. Ich habe mal noch den nördlichen Teil angehängt. Da ist ein wenig mehr Fels zu sehen.
Die Topo Schweiz von Garmin ist eine Raster und eine Vektorkarte zugleich. Die Endung *img sagt noch nichts über das eigentliche Format aus. Das ist nur ein Container für Vektor- und Rasterkarten. Bei der DAV Karte ist es genauso
Uebrigens kommen die Lawinen von oberhalb des gewählten weg...
[emoji12]Wenn es immer so wäre
Mir machen die Schneebretter, die man selber auslöst, mehr Sorgen. Von "Oben" kommt selten was ohne Grund. Meistens sind es die lieben Kollegen, die schon etwas weiter sind. Und da kann man immerhin Abstand halten. Aber wenn man selber über eine riskante Stelle geht, dann hat das was von russisch Roulette. -
In dem Bereich ist die Tabaccokarte unbestritten sehr gut. Eben weil die "ihr Handwerk" verstehen.
Aber nicht weil es eine Rasterkarte ist. Die hätten das bestimmt auch mit anderen Techniken so machen können.Nicht weil es eine Rasterkarte ist. Aber das Format lässt erst diese Fülle an Details zu. Wobei das eigentlich kein grundsätzliches Problem für Vektorkarten ist. Nur technisch ist heute nicht mehr drinnen.
Mir ist auch im Consumer Bereich kein anderes Vektorkartenformat bekannt, das eine ähnliche Detailfülle wie Rasterkarten abbilden kann. Und sogar die ATKIS Karten der LVAs haben deutlich an Details gegenüber den alten Rasterkarten eingebüßt. Hier wird sich teils beholfen, indem der Layer mit den Geländedetails als Rasterkarte über die Vektorkarte gelegt wird. Das alte Kartenbild war trotzdem besser, weil dort z.B. Mulden und Hügel durch zusätzliche Höhenlinien noch angezeigt wurden. Meine alte Top10 Bayern ist Gold wert, wenn es ohne Weg durchs Gelände geht. Auf die eingezeichneten Wege kann man sich aber kaum verlassen.
Primär ist der Inhalt einer Karte wichtig und muss zum Vorhaben passen. Das Format ist nur sekundär. Hat aber leider auch einen Einfluss auf den Inhalt.
@Barolo Und die können einem auch zeigen, wie man mit dem Lawinenpieps umgeht. Der bringt nämlich auch nichts, wenn man damit nicht halbwegs routiniert umgehen kann.
-
Ah ok, wenn das blaue der Winterweg ist...
Aber wenn da keine Schilder stehen, wie bekommt denn der Wanderer ohne GPS mit, wo er lang muss?Karte in der Hand, Augen im Kopf, Hirn an. Wintertouren sind ja nicht erst seit der zivilen GPS Nutzung möglich
Speichennippel Absturzgefahren und Lawinengefährdung sind zwei sehr verschiedene Dinge. Bei der Absturzgefahren geht es primär darum, ob ein Weg ausgesetzt ist und ob eine gewisse Fallhöhe möglich ist. Bei der Abschätzung der Lawinengefahr spielt das komplette Gelände um den Weg eine Rolle. So ist bei einem Weg entlang des Talbodens eines sehr spitz zulaufenden V Tales die Absturzgefahr garantiert gering. Die Lawinengefahr unter Umständen sehr hoch.
Unter Umständen, weil Vegetation und weitere topographische Merkmale eine Rolle spielen. Die Kartographen des Tabacco Verlages verstehen ihr Handwerk und geben genau das wieder, was ich wissen will. Und das flächendeckend, auf der gesamten Karte.
Das heißt nicht, dass OSM per se schlecht ist. Im Gegenteil, in den Mittelgebirgen sind die Karten oft besser als alles andere. Aber im alpinen Raum, wo es auf eine sehr detaillierte topographische Darstellung ankommt, gelangen Vektorformate als auch OSMs Ansatz "jeder Laie darf mal, vielleicht und irgendwie" an die Grenzen.
Wobei das auch wieder sehr abhängig vom Bedarf ist. Eine Alpenkarte auf der nur die Radwege verzeichnet sind, ist für eine Alpenüberquerung mit dem MTB Rad ideal. Und bestimmt auch schon sehr gut in OSM eingetragen.
Aber für die Anforderung "Alpenraum Skitouren, Wandern und Hochtouren", wie im Eingangsbeitrag gewünscht, halte ich OSM Karten für sub-optimal. Und es gibt ja zum Glück auch Besseres.
-
hmm, auf der Tabacco ist der 4B deutlich zu erkennenn. Ich hätte vom Kartenbild erstmal den Eindruck, dass dies der Hauptweg ist.
Der Track verlief dann über einen "schwarzen" Pfad, der bei OSM nicht mal vorhanden zu sein scheint, wenn ich das richtig sehe.Die blaue Linie gibt die Winterroute an. 4B ist der offizielle Sommerweg.
Die Symbole norwestlich des 4B und auch die des Tracks sind sich ziemlich ähnlich.
Wenn man nicht vor Ort ist und nur die Karten(n) zur Verfügung hat, woran erkennt man denn die Lawinengefahr?Indem man Karten lesen kann. Siehe roter Kreis
Beim nur Anschauen der Karten hätte ich jetzt das Gefühl die Tabacco ist veraltet, weil die OSM den genutzen Trackweg nicht kennt. Und Papier ist js bekanntermaßen geduldig..Deine Ansichten machen mir manchmal Angst.
Was das Einpflegen in OSM angeht, ist es klar besser, wenn das Leute vor Ort machen. aber die würden doch sicher auch entsprechende Schilder aufstellen, denke ich.Wo willst Du Schilder aufstellen, wenn dicke Schnee liegt? Und der Großteil der Touren geht über freies wegloses Gelände. Wenn Du dort ein Schild hinstellst, dann hast Du im Sommer sehr schnell einen neuen Weg. Und der Senner springt im Quadrat. Ne, so funktioniert das nicht im Winter. Da muss man selber mitdenken, sonst wird es schneller riskant als einem lieb ist.
Speichennippel Mir ist zwar nicht ganz klar, wie du die Felsen und die Geröllreise in OSM richtig abbilden willst, aber sicher, eine Datenbank ist geduldig. Nur dann ist die Sache noch nicht auf dem Gerät. Das Vektorformat von Garmin müsste das auch noch mitmachen. Und da sehe ich Grenzen. Würde Garmin nicht auf JPEG setzen sondern auf ein Format mit einem Alphakanal, könnte man theoretisch solche Stellen als Rasterkachel hinterlegen und über der Vektorebene anzeigen. Und solche Stellen in einzelnen Polygonen und Polylinien abzubilden dürfte das Format und die Rechenkapazität sprengen, wenn das flächendeckend durchgezogen wird. Mal abgesehen davon: Wer soll das bitte machen?
-
Ich hätte kein gutes Gefühl dabei, solche Wege in die Datenbank zu kloppen, nur weil ich die einmal gegangen bin. Wenn dann müssen das die zuständigen Leute vor Ort machen.
Winterrouten sind meistens auch keine konkreten Wege, sondern ungefähre Vorschläge, wo man halbwegs gefahrlos entlanggehen kann. Sie ersetzen nicht eine Entscheidung vor Ort.
Viel wichtiger ist, was man zusätzlich aus der Topokarte herauslesen kann. Dort ist nämlich die Lawinengefährdung für den Weg 4B zu erkennen. Der Vektorkarte fehlt es einfach an Darstellungsmöglichkeiten, um das ordentlich abzubilden.
Position: N46° 38.877 E011° 49.794
-
So würde ich das machen. Soviel spart man bei den Bundels auch wieder nicht. Und oft ist es nicht die Karte die man braucht.
-
Ja, zwischen Tracks und Routen ist ein riesiger Unterschied. Ein Track ist wie die Kieselsteinspur bei Hänsel und Gretel. Eine Kette von Punkten und das GPS zeigt Dir an, ob Du von dieser Spur abweichst. Nicht mehr und nicht weniger.
Das GPS benützt eine geodätische Projektion, um Koordinaten in Pixel auf dem Bildschirm darzustellen. Karten sind dazu unerheblich. Denn auch die Karten werden nur anhand dieser Projektion als das, was wir sehen, dargestellt. Du benötigst folglich keine Karte, um einen Track aufzuzeichnen oder ihn anzuzeigen.
Routen werden durch einzelne Ziele definiert. Der Weg von einem Ziel zum nächsten wird anhand der Kartendaten berechnet. Das funktioniert nur mit Vektorkarten. Bei einer Rasterkarte gibt es nur farbige Pixel die mit Hilfe der Projektion an die richtige Stelle gesetzt werden.
Bei Vektorkarten ist eine Straße als eine Ansammlung von Punkten hinterlegt und zusätzlich noch Information zu der Straße (Autobahn, Bundesstraße, Straße, Weg, Scheißweg). Damit kann ein Algorithmus einen "idealen" Weg berechnen. Das funktioniert im Straßenverkehr sehr gut. Im Freizeitbereich ist halt nicht genau definiert, was eine schöne, spannende, einfache oder schwere Tour ist. Hier kommt der Automatismus an seine Grenzen.
Man kann es so wie wasabi65 machen und Tracks in Routen umwandeln. Das funktioniert aber nur, wenn man auf der Planungssoftware, in diesem Fall zwingend Basecamp, und dem GPS die gleiche Karte benützt. Das ist nötig damit der Algorithmus auf dem Gerät zu dem selben Ergebnis kommt, wie der Algorithmus in der Planungssoftware.
Grundsätzlich gilt für jede Karte, dass man Vertrauen zu ihr aufbauen muss. Und man sollte sich im Klaren sein, dass nicht jede Karte überall perfekt ist. Es ist nicht zu empfehlen mal eben eine OSM Karte auf das Gerät zu wuppen und dann im vollen Vertrauen dieser Karte zu folgen.
Gerade OSM Karten sind sehr gebietsabhängig. Weißt Du welche Leuchte in einem Gebiet die Wege aufgenommen hat? Aber auch offizielle Karten haben ihre Mängel. Die offiziellen Karten von Bayern haben jeden Weg seit was weiß ich wann verzeichnet. Die meisten sind inzwischen Brombeersträucher und Brennnesseln.
Wären wir vor 2 Wochen in Südtirol der OSM Karte blind gefolgt, wären wir durch stark lawinengefährdetes Gebiet gegangen. Auf den Tabacco Karten war das eindeutig zu sehen und auch die Winterroute verzeichnet.
Es ist deswegen schwer eine generelle Empfehlung auszusprechen. Ich würde grundsätzlich im alpinen Bereich auf Routen verzichten und immer versuchen die selbe Karte in Papierform als auch auf dem Gerät zu haben. Tracks sind bestenfalls als Serviervorschlag zu betrachten. Vektorkarten spielen keine Rolle. In den Mittelgebirgen, mit ihren zahlreichen Forstwegen, aber ansonsten anspruchsloser Topographie, sind mir OSM Karten gute Begleiter.
Fang doch erst mal mit OSM Karten an. Im Bayerischen Wald, um Erfahrung zu sammeln. Und wenn Du dich im Kartenbild auskennst, dann vergleiche das mit hochalpinen Touren, die Du gemacht hast. Wenn Dir dann was fehlt, kannst Du ja immer noch nach kommerziellen Karten Ausschau halten. Das läuft Dir ja nicht weg. Und es ist immer einfacher Geld auszugeben, wenn man genau weiß warum.
-
Einem Track kannst Du auch ohne einer Karte folgen.
Vectorkarten sind nur nötig, wenn Du tatsächlich eine Route berechnen willst und dann den Anweisungen folgen willst. Das birgt aber einige Gefahren. Weg ist nicht gleich Weg. Damit dich das Gerät nicht auf einen steilen Single Trail führt, auf dem Du Fußgängern nur entgegen fällst und sie damit gefährdest, braucht es eine gewisse redaktionelle Aufbereitung der Daten. Und das Format muss das können.
Im OSM Bereich gibt es z.B. die Open - MTB Karten. Hier werden bevorzugte Radwege als Autobahnen deklariert. Somit routet das Gerät im KFZ Modus ideal. Wenn die Wege alle richtig getagt wurden.
Garmin hat sein Format weiterentwickelt. Offizielle Garminkarten, wie die Transalpin, können deswegen verschiedene Modi für Fahrräder anbieten. Aber auch hier gilt, redaktionelle Fehler können dazu führen, dass Du auf Wegen landest, die dein Können evtl. überfordern.
Deswegen sollte man sich nicht einfach auf das Routing vom Gerät verlassen, sondern vorab die Route berechnen, mit einer guten Karte abgleichen und gegebenenfalls den eigenen Fähigkeiten anpassen. Alpines Gebiet ist eben nicht der Bayerische Wald. Obwohl mir auch schon dort Leute mit dem Rad auf der Schulter entgegengekommen sind, die sich saftig verplant haben.
-
Für den Bayerischen Wald sind die Karten auf OSM Basis wohl die beste Wahl. In den offiziellen Karten gibt es immer noch zu viele Wege, die nicht mehr existieren. In dem Gebiet sollte auch die Routenberechnung kein Problem sein.
Bei "Alpenraum Skitouren, Wandern und Hochtouren" sehe ich eigentlich keinen Platz fürs Routing. Hier folgt man den aktuellen Gegebenheiten vor Ort und nicht einer berechneten Route. Das wäre Leichtsinn.
Zudem sind im alpinen Bereich Vektorkarten nicht so der Bringer. Du willst schließlich so viel Information wie möglich über das umliegenden Gelände bekommen. Deswegen bieten sich hier eher Rasterkarten an. Für die meisten Gebirgsstöcke der deutschen und österreichischen Alpen, bietet der DAV seine Karten auf einer SD Karte an. Diese Sammlung ist durchaus zu empfehlen.
Für die Schweiz sind die offiziellen Garminkarten vorbildlich (kombiniert Vektor/Raster). Die haben aber auch ihren stolzen Preis.
Für die südlichen Alpen gibt es nichts wirklich Gutes fertig. Ich habe mir dafür die Tabacco Karten eingescannt, referenziert und für das GPS aufbereitet.
-
Ich würde den Anteil der Jammermails in diesem Forum nicht als das Maß aller Dinge nehmen. Die meisten Benutzer haben begriffen, dass es 0.0 bringt, wenn man sich hier ausheult. Die Beschwerden werden inzwischen direkt vor Garmins Haustüre abgeliefert.
https://forum.garmin.de/activity.php
Nicht dass es wirklich was bringt. Aber es ist einfach weniger sinnlos. Denn was hier geschrieben wird, liest bei Garmin garantiert niemand.
Zum Thema: Der Schritt vom 60er zum 64er ist deutlich. Einige Nachteile, wie das Wegfallen der Tracknavigation, bringt er mit sich. Dafür aber auch viele Vorteile, wie eine deutlich flexiblere Daten- und Kartenverwaltung. Und eben nicht zuletzt auch die Rasterkarten.
Mechanisch ist das Batteriefach und die Halterung besser geworden. Dafür plagt man sich weiter mit Tastenabrieb. Und leider auch mit der Gummierung, die sich nach ca 4 Jahren bei meinem 62er langsam in Matsch auflöst. Das 64er hat leider keine andere Gummierung. Sprich die Probleme werden in ein paar Jahren die gleichen sein.
Im Vergleich zum Oregon ist der Empfang deutlich besser. Der verwendete Chipsatz ist gleich. Bei gutem Empfang ist der sehr präzise. Dafür sind die Abweichungen bei schlechtem Empfang deutlich größer als bei älteren Chipsätzen. Durch die bessere Antenne der 60er Serie kommt man erst später in diesen Bereich und früher wieder raus.
Im Vergleich zum Aventura/TwoNav sind die Garmingeräte primitiv. Das hat, wie alles, seine Vor- und Nachteile. Garmins sind auf wenige Funktionen beschränkt und damit sehr einfach zu bedienen. Wem das nicht reicht, der findet bei TwoNav ein wahres Eldorado an Funktion. Dementsprechend fordert die Bedienung aber auch einiges an Einarbeitung und Aufmerksamkeit während der Tour.
Wer gerade im Winter in den Bergen unterwegs ist, wird wohl mit dem 64er am besten beraten sein. Bei Kälte ist ein Tastengerät immer noch die erste Wahl. Mit Lithiumbatterien können die Temparturen auch mal deutlich unter 0 Grad liegen, ohne dass die Kapazität komplett einbricht. Bei strahlend blauem Himmel, Schnee und dem damit obligatorischen Sonnenschutz für die Augen, kann man das Display sehr gut ablesen (gilt auch für die Oregons). Bei einem Smartphone ist nichts mehr zu erkennen.
Wenn das Gerät eher für den Sommer bei gutem Wetter gedacht ist, kann man eigentlich alles nehmen. Da ist es dann eher Geschmackssache, ob Touchscreen oder Tasten. Und auch Smartphones lassen sich ablesen, solange man nicht direkt in der gleißenden Sonne steht.
-
Keine Ahnung was GNOME wieder als Sonderlocke macht.
Grundsätzlich ist es nicht nötig für QMS irgendwas einzuhängen. Das macht QMS bei Bedarf selber. Vor jeder Aktion wird das Medium eingehängt, dann werden die Daten ausgetauscht und danach wird das Medium wieder sofort ausgehängt. Wenn QMS mit einer Aktion fertig ist, dann kann man einfach das Gerät abziehen.
Wenn man QMS verlässt, wird auch nichts mehr an den Geräten gemacht. Wenn jetzt ein Power Off an das Gerät gesendet wird, dann ist das irgendwas anderes. QMS sendet nie einen Power Off.
Mit KDE ist das übrigens kein Problem.
-
Der rot markierte Satz sagt eigentlich alles
.... wenn man weiß wie Distributionen ticken.Folgendes: QT ist für viele Packetbetreuer viel zu groß. Das ist zwar, in Relation zu den Ressourcen eines heutigen Systems gesetzt, Quatsch. Aber solche Ansichten halten sich hartnäckig. Deshalb wird Qt in viele kleine Pakete zerteilt. Und wenn man etwas compilieren will, muss man zu jedem dieser Unterpakete auch das jeweilige Entwicklungspaket installieren.
In deinem Fall geht es um das Paket Qt Webkit. Schau mal in deiner Paketverwaltung nach, ob dieses Packet installiert ist und ob auch die Entwicklungskomponente (meistens mit einem "dev" markiert) installiert ist.
Wahrscheinlich kommen noch mehrere solche Meldungen. Dann muss man halt schauen, dass auch diese Pakete installiert werden.
-
-
Hätte mir auch klar sein müssen, dass eine knapp 100kb große VRT-Datei nicht 200 Dateien à 3mb ersetzen kann...
:D:D:D
Bei der VRT Datei geht es eigentlich nur darum eine Datei zu schaffen, die beschreibt wie sich die Karte zusammensetzt. In QLandkarte GT musste man das über das eigene *qmap Format machen. Da aber VRT direkt von GDAL verarbeitet werden kann, ist das der bessere Weg. Die meisten GDAL Befehle arbeiten auf einer VRT Datei übrigens schneller, als wenn man alle Dateien einzeln angibt.
In der VRT sind zwar jetzt relative Pfade angegeben, aber dafür ist das Attribut "relativeToVRT" auf "1" gesetzt, das klingt dann auch logisch.Ok, dann macht das gdalbuildvrt gleich vernünftig. Ich habe nie nachgesehen
Interessieren würde mich jetzt noch etwas genauer, wie ich an Infos zum Einbinden von Online-Karten komme? Für Karten habe ich schon die eine oder andere Beispiel-Datei gefunden (wmts, oder wie diese Formate heißen), aber für Höhe ist es mir noch nicht geglückt.
Dieses gesamte Umfeld könnte vielleicht noch etwas genauer dokumentiert sein.Bei den Höhendaten gibt es nur den Weg über lokale Dateien/VRT. Online Quellen werden nicht unterstützt.
Grundsätzlich lassen sich alle TMS Karten, die in QLGT funktionieren auch in QMS benützen. Eine Auswahl gibt es hier:
http://sourceforge.net/project…kartegt/files/WMS%20Maps/
Alles mit Endung *.tms.
WMTS Server muss man gezielt suchen. Die Definition von WMTS lässt aber so viele Extralocken zu, dass die aktuelle Implementierung nur einen sehr kleinen Teil unterstützt.
WMS habe ich gar nicht angefangen. Das ist noch chaotischer.
Ein Problem an den ganzen Online Karten ist, dass sie ständiger Betreuung bedürfen. Die Anbieter ändern nach Gutsherrenart laufend etwas. Da sie quasi auf ihren Servern tatsächlich die Gutsherren sind, ist das soweit ok. Aber um den ganzen Zirkus immer Folge zu leisten, muss man schon einen sehr großen Faible für Online Karten haben. Mir fehlt der komplett. Meine Welt sind offline Karten.
Ich bin übrigens auch begeisterter GPS-Tracker (eTrex 30), Openstreetmap-Zeichner, Linux-Freak und Software-Entwickler (auch Erfahrung mit Git, Bitbucket & co). Projekte wie QMS gefallen wir sehr gut.
Wenn ich mich irgendwie einbringen kann, sag Bescheid!Zu tun gibt es genug. Wie Du ja schon selber gemerkt hast, ist die Doku manchmal knapp. Diese aktuell zu halten und zu verbessern, frisst enorm viel Zeit, wenn man es gewissenhaft macht. Da meine Zeit für QMS auch ihre Grenzen kennt, und die Weiterentwicklung dann doch eine höhere Priorität geniest, als die Dokumentation, kommt leider nicht mehr, als das Vorhandene dabei raus.
Oft reicht es ein, zwei Sätze umzustellen oder hinzuzufügen. Das könnte zum Beispiel schon jeder. Eine gute, in sich logische Dokumentation, die immer auch das aktuelle GUI wiedergibt, benötigt laufend Zeit und Aufmerksamkeit. Dazu fühlt sich nur sehr selten jemand berufen.
Wer lieber programmiert und Online Karten liebt, der kann sich dem oben beschriebenen Komplex widmen. Aber auch hier reicht es eigentlich nicht, mal eben ein wenig Code zu spenden, den ich dann über die Jahre pflegen muss [1]. Hier muss man laufend anpassen und bereit sein auf Fehlerberichte zeitnah zu reagieren. Bzw auch von selbst Änderungen und Fehler zu entdecken, weil man sich laufend mit dem Thema beschäftigt. Halt eine Sache für echte Liebhaber.
Wer richtig dicke Bretter bohren will, der kann sich an Themen wie Offline-Routing a la BRouter versuchen. Aber bitte nicht einfach einen lokalen BRouter Server einbinden. Das ist keine wirklich portable und benutzerfreundliche Lösung. Sondern eher den Code von BRouter in eine Sprache, die auch außerhalb einer JRE Bestand hat, portieren. Bei C/C++ könnte jedes Projekt, egal welche Sprache es benutzt, davon profitieren.
Ein anderer monsterdicker Balken ist die Unterstützung von Mapsforge. Klingt super, bei näherer Betrachtung muss man schon sehr fest davon überzeugt sein. Auch hier stellt sich das Problem, dass sämtlicher Code im eher nutzlosen Java verfasst wurde und außerhalb der JRE/Android Blase somit wenig Nährwert entfaltet. Außerdem hat Mapsforge so ein paar Mängel, verglichen zum Garmin Format. Wobei "Mangel" schon reichlich gemein ausgedrückt ist. Mapsforge hat versucht eine möglichst schnelle und einfache Lösung zu finden, damit die Leute nicht mehr Kacheln für den Offline-Gebrauch saugen. Und dafür ist die Lösung echt gelungen. Leider denkt das Format aber deswegen nur in diesen typischen Kacheln. Eine längere Polyline zu extrahieren, die man zum Erstellen eines Planungstracks verwenden kann, wird zu einer Herausforderung. Da ist das Garminformat, neben der deutlich höheren Kompressionsdichte, einfach besser strukturiert. Aber wer der Meinung ist Mapsforgekarten sollen die Weltherrschaft erreichen, kann gerne meinen Code, der schon in QMS existiert, erweitern. Leider muss er auch den Mapnik Renderer portieren. Was mich dazu gebracht hat die Finger davon zu lassen.
Ein etwas dünneres Brett ist dann noch der GeoCache Support. Aktuell wird gc.com unterstützt. Oc.de würde sich auch über ein wenig Liebe freuen.
Natürlich darf man auch sein furchtbar vermisstes Lieblingsfeature einbauen. Eine vorherige Absprache mit mir wäre gut, weil ich nach über 8 Jahren Entwicklung oft ein wenig weiter denke. Erstens habe ich schon eine ganze Reihe von Designfehlern hinter mir (da ist aber noch Platz nach oben). Außerdem kenne ich die volle Palette von Wünschen. Nicht alles was auf den ersten Blick cool ist, passt sauber in die Software. Und und wenn man ein wenig größer denkt, dann könnte man gleich mehrere Probleme lösen. Ich weiß selber, dass das abschreckt (so wie die ganze Liste hier :D). Aber in QLGT sind oft solche kurzsichtigen Patche eingepflegt worden, die nachher eher zum Problem wurden, als dass sie ihren ursprünglichen Nutzen entfaltet haben. Wo wir bei der ominösen [1] von weiter Oben angelangt wären:
[1] Aus schlechter Erfahrung mit QLGT: Code der nicht aktiv betreut wird, fliegt raus, wenn er Probleme macht. Das ist nicht wirklich böse gemeint, aber ich habe mich schon mit zu vielen dampfenden Kackhäufen plagen müssen, was mir gegenüber eigentlich auch nicht nett ist.
Und wenn jemand meint angesichts dieser drückenden Fakten kann er doch eh nichts machen. Doch, auch als normal Sterblicher geht noch was. Wer mehr auf der sprachlichen Schiene schwimmt, kann sich mal sämtliche Textfelder in QMS und ihre deutsche Übersetzung ansehen. Beim Programmieren fällt mir nicht immer ein treffender Begriff auf Englisch ein. Und auch die längeren Texte treffen nicht immer den Nagel auf den Kopf. Nachher merke ich das selten, weil ich ja eh weiß wie alles funktioniert. Hier ist bestimmt noch einiges zu verbessern. Das würde nicht zuletzt den etwas weniger sattelfesten Benutzern helfen.
Wenn jemand gerne bloggt und dem Projekt was Gutes will, dann ist eine kleine Vorstellung sehr hilfreich die Leute von QLandkarte auf QMapShack umzuleiten. Aktuell wird QLGT noch ~100 mal am Tag von Sourceforge geladen (und da ist Linux nicht dabei) QMS hingegen alles zusammen ca 100mal pro Woche. Ja und wer lieber heftig über mich und mein Projekt lästert, darf das natürlich auch. Ich halte das wie mein Hund, der gerne im Drehkreuz meines Bürostuhles pennt: Besser über die Pfote gefahren bekommen, als gar keine Aufmerksamkeit
-
Um zu sehen ob für das aktuell betrachtete Gebiet überhaupt DEM Daten aktiv sind reicht es einen blick rechts unten auf die Statuszeile zu werfen. Wenn neben der Mauscursorposition auch eine Höhe angegeben wird, dann ist eigentlich alles in Ordnung.
Wenn die fehlt:
1) Hat man für das Gebiet auch wirklich DEM Daten?
2) Sind diese auch im *vrt eingebunden
3) Stimmen die Pfade im *vrt? Das Tool in QMS benützt absolute Pfade. Jede nachträgliche Änderung führt dazu, dass nichts mehr angezeigt wird.Sollte eine Höhe angezeigt werden:
1) Die Schummerung wird ab einem bestimmten Zoomlevel nicht mehr angezeigt. Nämlich dann wenn QMS mein, dass das auszulesende Gebiet zu groß ist und eine Berechnung zu lange dauert.
2) Sind der Transparenzregler und der sichtbare Bereich auf vernünftige Werte eingestellt. Steht der Transparenzregler ganz links sieht man nichts. Für den sichtbaren Bereich lässt man beide Knöpfe vorerst grün.
3) Der grüne Ring beim Neuberechnen der Karte zeigt an, dass der DEM Thread arbeitet. Solange der arbeitet wird nur die vorherige Ansicht skaliert angezeigt. Sieht man den nur sehr kurz, wird nichts berechnet.Ich hoffe das hilft
-
Dazu müsste es erst mal ein Angebot für gutes Geld geben. Und so werden alle die, die Kosten und Mühen scheuen ihre Kartenblätter digitalisieren zu lassen und selber zu referenzieren, auf solche Quellen zurückgreifen. Aber das lernen die Kartenverlage auch noch. Wahrscheinlich auf die selbe harte Tour, wie die Musik und Filmindustrie.
-
In den dunklen Ecken des Internets sind diese Karten schon seit Jahren als gescannte Geotiffs zu finden. Zwar in einer eher fragwürdigen Qualität, aber immerhin. Solche Kopien entstehen aus Mangel an legalen Angeboten. Nicht jeder ist in der Lage und willens Papierkarten zu scannen und zu referenzieren.
-
Aber was bringen die Karten dort, wenn man nichts erkennen kann... Die Idee ist ja nett, der praktische Nutzen geht bei starkem Sonnenschein gegen Null. Und für jede Karte eine andere halbgare Software auf dem Handy zu halten, ist auch nicht das Gelbe vom Ei. Also bleibt doch nur wieder das Popeln an der eigenen Lösung übrig. Praktisch geht anders.
Da sagt man "Danke" 