QMapShack

Jetzt kann ich es nachvollziehen. Sieht so aus als ob der Start und Endpunkt ein riesen Delta haben und sich der Graph sich den Wolf für die Marken auf der X-Achse rechnet. Mal sehe wie das zustande kommt....

Oh man eh. Man lernt auch nach über einem Vierteljahrhundert programmieren nicht aus. Der Fehler tritt immer auf, wenn man einen Track zurückdatiert. Weil, wenn man zwei unsigned int32 von einander abzieht und auf einen signed int64 schreibt, dann hat man leider noch lange nicht alles richtig gemacht. Ich sollte es besser wissen....

Schön dass wir darüber gesprochen haben. Bugfix ist im Repo Danke fürs Melden.

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

Zitat von HerrPi

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.

Zitat von HerrPi

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

Zitat von HerrPi

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.

Zitat von HerrPi

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

Da sagt man "Danke"

"When hell freezes over! KONSOLE?!?" LOL - mit der Windows Konsole macht es auch wirklich keinen Spaß. Cygwin ist immer das Erste, was ich auf einem Windowsrechner installiere.

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.

Seit heute ist die Version 1.0 draußen. Ich habe hierzu den ersten Beitrag geändert.

Habe ich mich auch schon gefragt ob das geht. Eine Datei habe ich aktuell nicht zur Hand. Aber hier wird die Sache beschrieben:

http://www.gdal.org/frmt_wms.html

Man muss dann noch eine VRT Datei dazu erstellen.

Sieht so aus als ob man die xml Dateien von QLGT benutzen kann. Ich glaube ich habe damals das Format nur erweitert. Es funktioniert. Aber es ist a...sch langsam.

Hallo Gert

In QMS öffnet man keine Karten als Datei. Man legt diese in einem Verzeichnis ab und dann werden sie automatisch gelistet. Siehe auch:

https://bitbucket.org/maproom/…ck/wiki/DocGettingStarted

und

https://bitbucket.org/maproom/qmapshack/wiki/DocBasicsMapDem

Nun werden allerdings die *xml Dateien als Endung, bzw Format nicht unterstützt. Wenn aber GDAL diese Dateien unterstützt (das weiß ich jetzt nicht für Windows), dann kann man auch die *xml Datei in eine *vrt Datei verpacken. Und dann mag auch QMS.