Eigentlich ist Projekt nur ein Synonym für Datei. Da aber QMapShack Dateien und Datenbank zugleich kann, ist der Begriff Datei nicht universell verwendbar. Deswegen wird der Begriff Projekt verwendet.
Wenn Du unbedingt einzelne Dateien haben willst, dann musst du ein Projekt pro Track anlegen.
Dein Garmin kommt aber auch mit mehreren Tracks in einer Datei zurecht.
Eine Route besteht in der Regel aus ein paar Punkten. Der Weg zwischen den Punkten wird berechnet. Ist also nicht genau vorgegeben.
Vorteil:
* Bei der Berechnung des Weges zwischen den Punkten kann man zusätzliche Information wie Abbiegehinweise hinzufügen.
* Ist der berechnete Weg versperrt oder man hat sich verfranzt, kann automatisch ein neuer Weg zum nächsten Punkt berechnet werden
Nachteil:
* Das Routenformat von GPX ist gelinde gesagt unter aller Sau und lässt viele Wünsche offen und auch viel Raum zur Interpretation. Routen sind deswegen nicht wirklich zwischen den Applikationen portabel. Das `G` und das `X` trifft somit nicht auf Routen zu.
* Berechnungen von Routen weichen zwischen den einzelnen Programmen ab. Ohne eine Datenbank mit Routing Daten geht eh nichts.
Ein Track ist die Aneinanderreihung von vielen einzelnen Punkten. Die Verbindung zwischen den Punkten ist immer eine Gerade. Damit kann man schön malen. Und wenn man den Track entlang von Wegen malt, dann kann man sich später anhand der schönen bunten Linie auch orientieren.
Vorteil:
* Tracks sind wirklich universal und werden von jeder Software gleich interpretiert.
* Tracks gehen auch, wenn es keine Daten zum berechnen von Routen gibt.
* Tracks funktionieren sogar ohne Karte.
Nachteil:
* Der Track kann nicht so einfach auf dem Gerät neu berechnet werden.
* Garmin-Geräte haben nur eine rudimentäre Funktion, um nach einem Track zu navigieren.
Wer Routen will muss im Universum des jeweiligen Anbieters bleiben. Also für Garmin heißt das Basecamp benutzen und nur Garmin Geräte verwenden.
Deswegen werden Touren heute als Tracks ausgetauscht. Wer wandert kommt mit einem Track relativ gut zurecht. Man muss halt das GPS immer im Auge behalten, um rechtzeitig abzubiegen. Radfahrer schätzen deswegen die automatischen Abbiegehinweise bei Routen.
Wenn ich es noch richtig im Kopf habe wird ein Zoom Level immer nur mit seinem Anfang definiert und geht solange, bis ein anderer anfängt. Für den letzten Zoom Level bedeutet das, dass alles bis zum größten Zoom abgedeckt wird.
Du müsstest folglich die Tabelle, die die Zoom Level definiert umschreiben und einen hinzufügen, der dann kein Kartenmaterial mehr hat. Und dafür musst Du dann noch ein paar mehr Tabellen anpassen. Das macht keiner.
Ist auch meiner Meinung nach nicht nötig. Ändere einfach die Draw Priority deiner JNX Karte, dann wird diese über der Vektorkarte gezeichnet, wenn der Zoom Level für die JNX Karte erreicht wurde. Das ist auch viel besser, weil Du dann immer noch die Vektorkarte siehst, wenn die JNX Karte keine Kachel für den Ausschnitt hat. Außerdem lässt sich die Tabelle, die die Zoom Levels definiert bei JNX deutlich einfacher manipulieren. Dazu gibt es auch Tools.
Wahrscheinlich sind die Daten zu viel. OSM Europa ist inzwischen ein echter Datenbolide.
In der Regel benötigt man das auch nicht. Ich habe mir zum Beispiel DACHI zusammengestellt. Und sollte ich doch mal wo anders sein, kann ich mir das nötige Gebiet recht schnell erstellen.
Als Alternative kann man auch BRouter lokal verwenden. Dann spart man sich auch das ständige bauen, weil BRouter seine Datenbasis zum Download anbietet.
Für Fußwege ist meiner Meinung nach Routino einen ticken besser. Fürs Fahrrad BRouter. Das fällt aber nur auf wenn man zwischen A und B routet. Benutzt man den Router um Tracks mit der Maus zu zeichnen ist es egal.
Bei Onlinekarten ist die Schrift ja auf der 256x256 Kachel als Pixelbrei. Da kann man nichts machen. Das Problem ist, dass dein HDPI Display die Kachel und alles andere nur halb so groß darstellt.
Der Wunsch die Displayauflösung zu beachten kam schon öfters. Wie üblich bleibt es aber immer bei der Forderung, weil es denen, die sich so einen Monitor leisten, in der Regel nicht darum geht sich selber einzubringen. Und ohne zwischen einer normalen und einer hohen Auflösung umschalten zu können, wird man das nicht fehlerfrei implementieren und testen könne.
Du kannst Natürlich für QMapShack grundsätzlich einen Skalierungsfaktor festlegen, um wieder auf die üblichen 100 DPI zu kommen. Siehe auch https://doc.qt.io/qt-5/highdpi.html Das geht allerdings zu Lasten der Schärfe.
Öööö, hast Du mir was geschickt? Ich finde nichts, auch nicht im Spamordner.
Wenn Du Lust hast darfst Du auch gerne an der Übersetzung feilen. Vieles davon ist irgendwann spät Abends entstanden und nicht immer wirklich gut gelungen. Also eher selten gut gelungen...
Ja sollte ok sein
Ein kleiner Übersetzungsfehler ist mir augefallen, dafür schreibe ich jetzt keinen Report auf github.
Das wäre auch kein wirkliche Hilfe. Eine wirkliche Hilfe wäre es sich den Qt Linguist zu schnappen und damit die Datei "src/qmapshack/locale/qmapshack_de,ts" zu fixen. Da gibt es bestimmt noch mehr zu finden oder auch besser zu übersetzen. Die geänderte Datei kann mir schicken. Für Übersetzungen braucht es keinen vollständigen Pull Request.
Nej, deren Github: Waymarkedtrails... da müsste ja schon etwas dabei sein dass ich (ohne jemandem zu schaden oä) nutzen kann.
Ah, jetzt macht das alles mehr Sinn 
Ich wüste jetzt von keiner fertigen GPX Datei mit einem Wegesystem. Aber frag doch bei denen nach. Die können Dir zu mindestens sagen welcher Teil im Code das Wegenetz liest. Von dort muss man dann "nur noch" alles in eine GPX Datei schreiben anstatt zu rendern.
Du musst gar nichts aus dem Repo nehmen. Wie kommst Du denn darauf? Dort liegt der Sourcecode von QMapShack und das Wiki. Sonst nichts.
Wenn Du offline Wanderwege haben willst, musst Du dir GPX Dateien mit Tracks zusammensuchen. Die gibt es bei den einschlägigen Onlineportalen z.B. Outdooractive.
Theoretisch kann man auch alle Wanderwege aus der OSM Datenbank auslesen und in Tracks umwandeln. Möglich dass das schon jemand für dich gemacht hat und die Ergebnisse veröffentlicht hat. Das hat aber nichts mit QMapShack zu tun sondern mit OSM. Also mal dort nachfragen oder suchen gehen.
Diverse Wanderführer bieten ihre Touren auch als GPX an. Dazu muss man aber das Buch kaufen, um an einen Downloadcode zu kommen.
Und die meisten Leute benutzen einfach QMapShack mit Garminkarten bzw Rasterkarten und einer Routingdatenbank, um sich ihre Touren selber zusammenzuklicken. Aber dazu muss man sich ein wenig im Wiki einlesen.
Also zunächst möchte ich mal klarstellen, dass diese Karte nicht von mir ist. Ich bin weder der Autor der Karte noch betreibe ich den Webserver. Dank und Cudos gebühren den Machern von Waymarkedtrails.
Und da sind wir auch schon beim eigentlichen Knackpunkt: Das ist eine Onlinekarte und die Betreiber des Servers haben kein Interesse daran, dass du sie Offline ziehst. Im Gegenteil, sie verbitten es sich, weil sie das nur Bandbreite und damit tatsächlich Geld kostet.
Wenn du all das offline haben willst, musst Du entweder das nehmen, was vorhanden ist (Rasterkarte, Garminkarten, lokale DEM Dateien und Tracksammlungen), oder selbst tätig werden. Denn Du kannst natürlich genauso wie Waymarkedtrails aus frei zugänglichen Daten deine eigenen Karten generieren und auch eine Tracksammlung mit Wanderwegen, die du mit Höhendaten aufbereitet hast etc.
Auf der Wikiseite von QMapShack wurden schon zahlreiche Quellen von halbwegs aufbereiteten Karten und DEM Daten gesammelt. Offline- als auch Onlinematerial:
https://github.com/Maproom/qmapshack/wiki/DocMapDemSources
Wenn das nicht reicht musst Du dich beim OSM Projekt einlesen, wie man einen eigenen Kachelserver betreibt, denn Du dann lokal auf deinem Laptop laufen lässt. Und Du musst herausfinden, wie die die Wanderwege aus den OSM Daten extrahierst und Tracks daraus erstellst. Wenn das gelingt, dann bietet dir QMapShack alles um damit zu arbeiten und zu planen.
Ach ja wie lustig. Da sieht man eigentlich nur den ganzen Wahnsinn des Themas. Bei QLandkarte habe ich genau das Gleiche gemacht und bin dann davon abgekommen. Also komplett die andere Richtung.
Eine reine Mittelwertbildung mit einem linearen Filter, geht halt nur mit Aufzeichnungen, die die Abtastkriterien einhalten. Das trifft auf kaum einen Track zu, den man so im Internet findet. Und die meisten Benutzer sind sich dessen nicht bewusst und stellen ihre Geräte nicht dem entsprechend ein. Also habe ich mich eines Algorithmus aus der Bildverarbeitung von Satelliten beholfen. Dem Medianfilter (Hint: den gibt es heute noch in QMapShack) Nach einer Medianfilterung wurde der Auf- und Abstieg ganz klassich über die Summe der Deltas berechnet.
Das Ergebnis war mir dann aber doch zu wenig nachvollziehbar und auch zu abhängig von der Qualität der Aufzeichnung. Mit der Hysterese ist die Streuung geringer. Klar, große Ausreißer schlagen hier voll zu Buche. Allerdings sind die Empfänger inzwischen dann doch etwas besser und wer solche Berechnungen nur mit der reinen GPS Höhe anstellt ist selber Schuld.
Aber wie schon gesagt, hier darf jeder seiner eigenen "Religion" folgen. Wir kenne alle nicht den wirklichen Wert von Auf- und Abstieg.
Wo radelst du, dass du 1773 hm Flachland nennst?
:-))
Natürlich nicht 
Aber wenn ich deine Ausführung richtig verstanden habe, addierst Du alle Deltas und belegst das Ergebnis mit einem Korrekturfaktor, um das Rauschen zu kompensieren. Richtig?
Kann man so machen. Naturgemäß kommt man damit auf etwas mehr Höhenmeter, da wirklich jeder Anstieg und sei er noch so gering, gewertet wird. Zudem ist das Ganze auch recht abhängig von der Menge der Messwerte. Je enger das Raster, je mehr Deltas könne zum Auf- und Abstieg beitragen.
Man kann das natürlich auch anders sehen. Ein Bergsteiger würde jetzt nicht jede Bodenwelle mit einbeziehen, wenn er eine Tour einschätzen will. Es sei denn er will seine Leistung schön rechnen Deswegen auch die Idee mit der Hysterese von 5m. Wenn die Bodenwelle 5m hat, dann wird sie mitgenommen. Ansonsten kann ich zwischen den 5m Linien so oft ich will ein paar Meter an- und absteigen, es bleibt eine Bewegung in der Ebene, die nicht beiträgt.
Wie man das sieht und welchen Algorithmus man für besser hält ist eigentlich egal, wenn man zu mindestens zwei Dinge akzeptiert:
* Einfach alle Deltas aufzuaddieren, ohne irgend etwas anderes zu machen, ist der denkbar schlechteste Algorithmus.
* Um Touren über die Höhenmeter vergleichen zu können, sollte man konsequent immer beim selben Algorithmus und der selben Parametrierung bleiben.
Nur so kann man zum Schluss sagen, dass die Tour A mit 1200 Hm anspruchsvoller ist als die Tour B mit 800Hm. Wenn ich mir teilweise die Angaben auf Tourportalen ansehe, dann wird das nicht eingehalten. Meine eigenes Tourenarchiv geht bis 2006 zurück und umfasst 3 Garmin Generationen. Die Ergebnisse für Touren, die ich während dieser Zeit mehrmals gegangen bin, sind erstaunlich ähnlich. Wie viele Höhenmeter es genau waren, werde ich nie wissen 
Der Wert und der Algorithmus sind über die Zeit empirisch entstanden und liefern für GPS Aufzeichnungen aller Art halbwegs realistische Werte. Die Diskussion zu den Höhenmetern gibt es seit dem es GPS Geräte gibt. Vorher hat man Höhenlinien gezählt.
Im Grunde macht das auch QMapShack so. Es zählt die über- und unterschrittenen 5m Höhenlinien. Das liefert bei echten Anstiegen gute Werte, die halbwegs unabhängig von der Anzahl der Messwerte und den Fehlern des Gerätes sind. Für andere Experimente wie Radeln im Flachland und 20mal um den Parkplatz rennen ist diese Art der Berechnung nicht zu gebrauchen. Anderseits muss man sich auch ernsthaft fragen, warum man bei solchen Aktivitäten den Anstieg der Höhenmeter überhaupt wissen will.
Der Schwerpunkt bei QMapShack liegt beim Planen, Auswerten und Archivieren von Touren. Und das für ein Publikum, das so etwas überhaupt noch auf dem PC macht. Als QMapShack noch von Bitbucket gehostet wurde lief eine Zeitlang Google Analytics mit. Das Publikum von QMapShack ist männlich und 45..70 Jahre alt. Für dieses Publikum sind die schon vorhandenen Möglichkeiten Dinge zu konfigurieren eine Zumutung bis hin zur Überforderung. Das ist aber die Zielgruppe.
QMapShack kann vieles und auch vieles nicht. Wer wissenschaftlich mit Karten und GIS Daten arbeiten will, benützt eher QGis. Wer trainieren will benutzt Software in der Cloud. Wer noch tollere Experimente machen will, kann mit Skriptsprache und Datenbanken umgehen.
Die Benutzer von QMapShack sind glücklich, wenn sie ihre Tracks auf dem Bildschirm sehen und ein paar Auswertungen dazu. Eine Diskussion, wie diese Daten zustande kommen und wie man Parameter einstellen müsste, um das Ergebnis zu optimieren interessiert die wenigsten.
Deswegen müsste es schon sehr gute Argumenten für einen konfigurierbaren Parameter geben. Und dann stellt sich immer noch die Frage, wie man das kommuniziert, bzw sogar automatisch richtig machen kann. Es gibt schon zu viel Software, die in Konfigurationsparametern ertränkt wurden, nur weil man es jedem irgendwie recht machen wollte.
Ich bin durchaus offen darüber zu diskutieren, ob der aktuelle Algorithmus und die aktuelle Parametrierung das gelbe vom Ei sind. Und wenn gezeigt werden kann, dass es etwas Besseres gibt, das für viele Geräte eine Verbesserung bringt, bin ich dabei. Eine Optimierung für einzelne Anwendungen bzw. Geräte kann aber nur passieren, wenn dadurch der Rest nicht leiden muss.
In diesem Sinne der aktuelle Algorithmus ein halbwegs akzeptabler Kompromiss.
In QMapShack gibt es keine Funktion, um Segmente zusammenzuführen. Das war bisher auch kein Problem, weil auf den Geräten der ganze Track angezeigt wird. Und die Geräte selber Tracks mit mehreren Segmenten anlegen. Also ein durchaus gängiges Verhalten. Ich finde eher das Verhalten von Garmin Connect seltsam, weil es Segmente in einer Art und Weise interpretiert, die sich nicht wirklich als sinnvoll erschließt.
Ah, ok. Gibt es leider für die Erweiterungen, die von QMapShack eingeführt werden, nicht.
Ja. Deswegen ja auch die Verweise auf die jeweiligen Pull Requests und nicht auf eine veröffentlichte Version
Bei den Karten, den User Agent umbenennen:
https://github.com/Maproom/qmapshack/pull/169
ZitatEin paar Fragen hab ich natürlich auch noch.
Zu den Karten. Da ich es auch auf einem Surface verwenden möchte, der nicht immer am Netz hängt, wollte ich einen Kartensatz auch lokal speichern. Da habe ich mir diverse angegebene Formate direkt von OSM heruntergeladen, die werden aber von QMS nicht erkannt. Woran kann das liegen ?
Im Wiki steht alles über unterstützte Formate und zusätzlich ein lange Liste von Kartenquellen:
https://github.com/Maproom/qmapshack/wiki/DocMapDemSources
ZitatGibt es vielleicht auch eine (von mir aus auch abgespeckte) Android-Version, oder ist sowas geplant ?
Nein. Nein.
ZitatGibt es beim Routing vielleicht eine Möglilchkeit der automatischen Sortierung der Routenpunkte nach kürzester Verbindungsstrecke nach Festlegung von Start- und Zielpunkt ? Bisher muß ich sie noch per Hand verschieben, wobei die Reihenfolge nach Sortierung auch nicht gespeichert wird.
https://github.com/Maproom/qmapshack/pull/141
ZitatDa ich QMS als reinen Show-and-Edit-Knecht verwende, und eine Reihe weiterer Daten dazu in Excel bzw, Open Office verwalte, wäre eine Bearbeitungsmöglichkeit der GPX-Dateien sehr sinnvoll. Gibt es da einen entsprechenden XML-Filter ? Was ich bisher im Netz gefunden habe, war nicht wirklich die Wolke.
Keine Ahnung was Du willst 
