Beiträge von kiozen

Da kommt es dann wahrscheinlich im Wagen zu eheähnlichen Ausnahmezuständen

Zitat von anesthesia

Guter Vorschlag und schon umgesetzt.

Psst nicht schon vorab alles verraten

Zitat von anesthesia

Kiozen, könntest du den Punkt hervorheben? Ich habs mal schwarz markiert, hoffentlich erkennbar!

Ööööö, was soll ich? Einen schwarzen Knödel malen? Und was bringt das?

Das glaube ich dir gerne. Hilft nur nix. Sehe es als zusätzliches Training an. Am Fahrzeug und Fahrstil wird ja auch immer wieder gefeilt, um zu gewinnen.

Ok, das liest sich jetzt aber schon ein wenig anders als am Anfang. Ich glaub wenn Du wirklich Hilfe bekommen möchtest, dann solltest Du mal genau sagen was Du willst. Welche Karte, von welchem Server willst Du ausdrucken. Und was willst Du damit machen.

Zitat

Es gibt aber auch Teams, die dazu ein Tablet einsetzen und die Daten vorab eingeben um sie am ausgangspunkt der Peilung nur noch abzurufen.
Die Info, um welche Software es sich handelt wird als Betriebsgeheimnis gehandelt.

...

Zitat von Aynchel

und selber ein Programm schreiben ? ich ?
nee Du, Schuster bleib bei deinen Leisten
ich bin froh wenn ichs Mobile eingeschaltet bekomme

Dann würde ich sagen klarer Fall von: Hirn 1:0 Muskeln

Ich denke nämlich, dass die anderen sich was selber geschrieben haben.

Zitat von papaluna

Du meinst die gesetzten Trackpunkte beim zeichnen!?

Genau. Die explizit von dir gesetzten Puknte.

Zitat von papaluna

Wenn ein größerer Abstand per Definition/Konfiguration möglich wäre, würde das dann dazu führen das über die nun längere Distanz zwischen den beiden Punkten entlang der Linien, eine Tracklinie und nicht Luftlinie gezeichnet würde?

Das wären dann aber auch größere Fangradien. Das will man nicht. Und manchmal will man ja mit einer Luftlinie abkürzen. Das wäre dann nicht mehr möglich.

Zitat von papaluna

Bzgl. deines obigen Einwand bzgl. Mauer und der Frage ob es gegebenenfalls überhaupt möglich ist, an der Stelle wo Linien aufeinandertreffen, weiterzukommen, kann ich für mich sagen, das in dem Moment wo ich den Track zu zeichnen beginne, ich mir doch soweit machbar(Luftbild, Rasterkarte etc) bereits ein Bild gemacht und entschieden habe ob dies wahrscheinlich möglich ist.
Wenn nein, zeichne ich doch erst gar nicht den Track über diese Stelle.

Das eine ist ein bewusstes Zeichnen, das andere ein Ergebnis von einem Automatismus. Wenn ich bewusst 2 Punkte an einer Stelle setze und mich über eine eventuell sichtbare Lücke hinwegsetze, dann habe ich das gemacht und zu verantworten.

Wenn der Automatismus das macht, obwohl in der Karte eindeutig kodiert war, dass man hier nicht drüber kommt, dann ist das für den Benutzer ein Bug in der Software.

Die einzig saubere Lösung ist meiner Meinung nach Routing. Und da das fehlt ist es eben aktuell nur Freihandmalen, mit ein wenig Unterstützung.

Wegen der Fangradien. Und weil beim Stückeln der Linie etwas optimiert wird, um doppelte Punkte zu vermeiden. In dem Moment wo der letzte Punkt der einen Linie und der erste Punkt der anderen Linie nahe genug sind, gehe ich davon aus, dass es sich um eine fortgesetzte Linie handelt. Sind die zu weit auseinander, nehme ich Luftlinienrouting an.

Das Kriterium hierzu ist folglich nicht die Relation der Linien zueinander, sondern einfach nur der Abstand der Punkte.

Also Google sagt mir:

http://wiki.openstreetmap.org/…_erzeugen_bzw._ausdrucken

Zitat von papaluna

Aber wenn ich doch den Track schon auf einer Linie teilweise gezeichnet habe dann auf die folgende Linie zeige, diese auch vom System schon markiert wird, gehe ich als Laie davon aus das die Abfolge der noch nicht gezeichnet Punkte damit schon eindeutig klar ist.

Aktuell gehst Du mit der Maus über eine Linie und die wird zuerst mal nur hervorgehoben. Schließlich weiß noch niemand, ob Du diese Linie überhaupt brauchst. Wenn Du klickst, ist das der Einstiegspunkt in die Linie. Bei einem zweiten Klick auf die Linie, wird diese zwischen den zwei Punkten als Track übernommen.

Klickst Du nur einmal auf die Linie und gehst dann zu einer anderen Linie, dann entsteht eine Luftline. Der Algorithmus sieht ja nicht die räumliche Zugehörigkeit wie wir. Und auch wenn Straßenenden nahe zusammenliegen, heißt das nicht, dass man über diese Stelle drüber gehen kann. Vielleicht ist da ja eine Mauer? Oder Enden liegen leider nicht so nahe zusammen, wie sie sollten und die Stelle wird fälschlicherweise als unüberwindbar erkannt.

Folglich muss bei einer Linie immer abgespeichert werden, an welche Linien sie anknüpft, um das von Dir gewünschte Verhalten zu bekommen. Und das ist der erste Schritt Richtung Routing. Der zweite wäre jetzt aus den möglichen Alternativen auszuwählen.

Da sind 2 Bedingungen einzuhalten:

1) Wegpunkte können Bilder mit dem gleichen Namen enthalten. Deswegen werden die Dateinamen automatisch mit einer Laufzahl versehen.

2) Bei der Trackerstellung ist ja nicht bekannt, ob auch die Wegpunkte übertragen werden. Das kann man bei QLGT halten wie man will. Deswegen werden die 2 Mal abgespeichert.

In QMS ist das aktuell auch so. Man könnte es hier zwar anders machen, weil ja alles in einem Projekt übertragen wird. Das würde den Code aber reichlich kompliziert machen. Und da die Bilder in der Regel nicht so besonders groß sind und SD Kartenspeicher billig, habe ich es mir einfach gemacht.

Zitat von papaluna

Ja. Würde ich auch so handhaben.

Trackprofil:

Beabsichtigst du die verfügbaren Funktionalitäten von Qland zu portieren?
Was hälst du von der Möglichkeit via Wegpunkticon direkt zur Position in der 2D-Karte und/oder den Eigenschaften des Punktes zukommen?

Mir ist nicht ganz klar was Du alles meinst.

Zitat von papaluna

Aber es gibt ja bereits eine Art snap&draw beim zeichnen von Tracks entlang von Linien.
Ein Erleichterung wäre hier doch schon, wenn man einen Punkt auf der folgenden Linie markieren könnte und dann automatisch der Track entlang Linie bis dorthin gezeichnet wird ohne der Linie nachfahren zu müssen.
Das würde eigentlich völlig ausreichen und setzt doch keine Routingengine vorraus.

Leider ist man da schon mitten im Routing. Das Ende der einen Linie weiß ja nicht wo es weiter geht. Diese Information muss irgendwo codiert sein. Nämlich in der Routingtabelle. Ob man jetzt die aus den Garmin Dateien nimmt oder z.B. aus den BRouter Tabellen, ist schon egal. Man muss quasi von Punkt A nach Punkt B eine Route berechnen, die über die ganzen Teilstücke der Linie führt.

Ich sehe da eher die Zukunft in so etwas wie BRouter. Damit ist das Routing vom Kartentyp abgehoben. Ähnlich wie die DEM Daten. Und sich der Illusion hinzugeben, wir könnten irgendwann eine Route mit den Garmindaten so berechnen, dass sich diese 1:1 auf einem Gerät umsetzen lässt, halte ich für aussichtslos. Dann doch eher eine intelligente Tracknavigation auf Daten, die von der Karte unabhängig sind. Das hätte etwas Neues.

Wobei das auch nur wieder von einem sehr kleinen Kreis von TwoNav Benutzern benötigt wird. Möglich dass Locus was Ähnliches kennt. Bei Garmin wird die Tracknavigation nur sehr dürr umgesetzt. Die wollen Karten für ihr Active Routing verkaufen.

Dann mach ich das so: Wenn ein guter konkreter Vorschlag kommt, baue ich das ein.

Was wirklich fehlt, ist ein guter offline Router. Dann könnte man solche Roadbooks auch automatisch erstellen. Konkret zu Disposition steht den BRouter von Java nach C/C++ zu portieren. Aber den Aufwand betreibt man wohl nur wenn man das wirklich braucht. Und der Bedarf fehlt leider bei mir.

Zitat von MiLeo

Da geht es mir ähnlich wie papaluna.
Wichtig sind mir die Entfernungen, Höhenmeter und (falls vorhanden) Geh-bzw Fahrzeiten zwischen den einzelnen Punkten. Auch sehr hilfreich wenn man die Tour mal abbrechen oder ändern muss.
Nice to have:
- Wegpunktsymbole oder Bilder (zb die Abbiegepfeile die man den Wegpunkten zuordnen kann - eben wie ein Roadbook)
- am Wegpunkt bereits absolvierte Strecke, Höhenmeter und Zeit in Prozent der Gesamtstrecke

Alles anzeigen

Das kann man sicherlich noch in einer zusätzlichen Spalte unterbringen. Nur wie soll es aussehen? Da ich die Liste eigentlich nie benutze, fehlt mir der praktische Bezug. Die Liste in QLGT ist zu überfrachtet, bzw zu unübersichtlich. Insofern wäre ein konkreter Vorschlag zu Inhalt und Gestaltung eine große Hilfe. Dabei geht eigentlich fast alles was mit HTML auch geht.

Zitat von MiLeo

Ausserdem noch ein Frage zu QMS (wohl an kiozen):
Kann man das Höhenprofil in der Kartenansicht (selber) größer machen? Klar gibt es eine eigene Ansicht für das Höhenprofil. Aber ich würde gern das Profil mit der Maus abfahren und gleichzeitig sehen wo der Punkt auf der Karte liegt. Dafür ist mir das vorhanden Profil-Fenster etwas zu klein. Praktisch wäre es wenn man es anpassen könnte wie man es gerade braucht.

Muss ich mal sehen wie ich das unterbringe.

Zitat

Für Twonav-Nutzer wäre es dann optimal wenn diese "Bilder" als Skizzen im Roadbooktrack auftauchen würden.

Das sollte in QLGT so sein, da diese Bilder dem Roadbook-Punkt als Bilddatei angehängt werden.

Zitat

Läßt sich die Liste dieser Piktogramme eigentlich bei Bedarf erweitern ?

Die Liste selber nicht. Du kannst jedoch einfach deine eigenen Skizzen als Bild laden.

Aber ist das nicht viel zu aufwändig? Ich habe am Anfang mal 2-3 Touren so aufbereitet. Viel Arbeit, aber eigentlich folgt man dem Track, bzw lässt die Route berechnen. Es kamen dazu auch nie groß Rückfragen. Insofern denke ich hat das nie jemand wirklich benutzt.

Zitat von papaluna

Im klassischen Sinn würde imo ein Roadbook nur Sinn machen wenn es eine Strecke komplett beschreibt(Bsp. Rallysport) und das ganze dann auch noch ausdruckt werden kann..
Diesen Aufwand wird man vermutlich nur bei ganz bestimmten Unternehmungen/Expeditionen betreiben. Für die üblichen Wochenend-/Urlaubstouren wohl eher weniger. Das ganze wäre dann z.B in Verbindung mit Papierkarten ein gutes Backup, welches z.B. ohne Verfügbarkeit von Energie z.B. im Falle eines Geräteausfalles zur Verfügung steht.

Eigentlich wäre ja dann die Projektzusammenfassung der bessere Platz. Und zwar gruppiert man die einzelnen Objekte nicht nach Typ, sondern die Wegpunkte entlang das Tracks. Ungefähr so wie im Anhang.

Hm, ob das besser ist?

Zitat von joshl

Hi Kiozen,

was auffällt ist, das bei Start mit Admin unter "c:\Users\ANWENDERNAME\.config\QLandkarte\" die workspace.db erzeugt wird und WaypointIcons angelegt wird. (Verzeichnis "QLandkarte" vor Start immer gelöscht.
Starte ich nicht als Admin wird nur "c:\Users\ANWENDERNAME\.config\QLandkarte\" angelegt. Der Inhalt fehlt.

Ok, das ist schlecht. Vielleicht hängt QMS ja beim öffnen der Datenbank und deswegen geht nichts weiter.

Zitat von joshl

Da schau her. Als Admin gestartet und alle Versionen laufen. Da will er an irgend etwas dran, was er nicht darf.

Klar QMS will an deine rechte Maustaste dran.

Ne keine Ahnung, was der Unterschied zur linken Maustaste ist. Das sind Events, die vom System an QT gereicht werden und von dort an die entsprechenden Objekte. Als Reaktion auf den Event wird ein Kontextmenü erstellt. Keine Ahnung ob Windows hier Restriktionen hat.

Zitat von papaluna

Hi Oliver,
mir ist gerade aufgefallen das die Werte für eine transparente Farbe und die Farbtoleranz, sofern sie in der RMAP drin stehen, anscheinend nicht ausgewertet werden.

Ich würde vom RMAP Support nicht zu viel erwarten. Das ist nur der Code wie er in QLGT drinnen ist. Und das war nur das was nötig ist, um die exportierten RMAP Dateien zu verifizieren.

Ich halte es bei den Rasterkarten ähnlich wie bei den Daten. Karten sind auf dem PC in einem offenen Format und werden zum Gebrauch auf den Geräten entsprechend umgewandelt.

Wer aber Lust auf RMAP Hacking hat, der kann gerne den Code erweitern.

Zitat von joshl

Ich habe die Version getestet. Gleicher Effekt.
Leider kann ich auch nicht mehr exakt sagen, wann das Problem aufgetreten ist. Ich habe die Entwicklung verfolgt und vor Längerem trat das Problem auf, das bis jetzt vorhanden ist. Aus Zeitmangel habe ich mich nicht darum gekümmert. Meine Maus ist eine 0815 Logitech USB Funkmaus.

Hast Du ach mal komplett alles installiert? Also auch die Microsoft Bibliotheken? Nicht das es da zu einem Problem gekommen ist. Die linke Maustaste und das Mausrad funktionieren wie erwartet?

Nachdem ich nun Wegpunkte einem Track zuweisen kann, jetzt auch für den Hin- und Rückweg, stellt sich die Frage, ob es wieder so etwas wie ein Roadbook geben soll. In QLGT waren das die Etappen im Trackedit Dialog.

So richtig zufrieden war ich mit der Tabelle aber nie. Sie ist reichlich unübersichtlich. Außerdem hatte sie wenig Nährwert bei der Planung und der Auswertung.

Braucht man das wirklich? Und wenn, ja, was wäre denn praktisch? Jetzt mal abgehoben von existierender Software, welche Information, wie dargestellt, würde einem richtig weiterhelfen?

Wenn man die Höhendaten in einem offenen Format hat kann man auch QLandkarte oder QMapShack benutzen. Dort wird das in den Alpen übliche Warnschema unterstützt. Sieht dann so aus:

https://bitbucket.org/maproom/…ntrolMapDem/maproom10.png