Beiträge von kiozen

Ich glaube eher, dass es dem Designer sonst zu klein für eine Erwachsenenhand geraten wäre. Früher war es ein wuchtiger Plastikrand, der verschrammelte. Heute ist es verstärktes Glas. Und wenn es einem nicht gefällt, lässt man es bleiben.

Zusammen mit dem Biergarten können es schon 8-10h werden. Klar, kann man dort ausschalten. Kann man aber auch vergessen. Wenn ich bedenke wie oft mein Sportiva mitten auf der Tour leer war, weil ich vergessen habe es am Vorabend auszuschalten. Man sieht ja nicht ob es an oder aus ist. Da ist ein Ersatzakku eine feine Sache. Wirklich.

Ich hoffe für Compe, dass der Akku nicht wieder das Zünglein an der Waage bei der Entscheidung der Käufer ist. Zumal sich auch umweltpolitisch der Wind gegen fest verbaute Akkus wendet. Was sicherlich nicht ganz spurlos an den Köpfen der Verbraucher vorbeizieht.

Aber es ist egal was wir beide denken. Der Markt macht es.

Die Stückzahlen werden auch nicht besser, wenn ich mir überlege, wie oft ich schon gelesen habe, dass Benutzer wegen dem fest verbauten Akku dann doch lieber das Oregon anstatt dem Edge gekauft habe.

Aber Compe wird sich schon was dabei gedacht haben. Zumal sie versuchen in einen Markt zu kommen, bei dem es noch viele andere Hersteller gibt. Bei Fahrradnavis gibt es ja noch echte Konkurrenz (Falk, Mio, Garmin).

Hm, Akkus mitschleppen, um Akkus zu laden. Ist das wirklich so erstrebenswert?

Jetzt wäre halt gut. Der Gummi über dem Powerbutton hält nicht mehr lange. Sprich es steht eine Kaufentscheidung an. Aber egal hier geht es um ein anderes Gerät.

Verrückter Weise habe ich damit auch bei meinem S5mini Probleme, weil die aktuellen Hosen so besch... Taschen haben

Wobei sicherlich Gewicht und Kontakt auf dem Fahrrad bei harten Schlägen mehr Auswirkungen haben. Ich befürchte nur, dass ähnlich wie beim Edge, der fest verbaute Akku und die damit limitierte Laufzeit, die Kaufentscheidung herabsetzt.

Compe wird schon wissen was es macht. Wobei ein ordentliches Tastengerät mit gescheitem Display und gutem Empfang gerade eher meinem aktuellen Bedarf entspricht.

Ein Ersatz für den Aventura wäre spannender

Warum muss bei Fahrradnavis eigentlich immer der Akku fest verbaut sein? Mach Garmin auch so. Haben die Angst wegen den Kontakten?

Bescheiden ist der richtige Ausdruck Nee, das ist jetzt gemein.

Aber ehrlich gesagt bin ich kein Freund von vielen Optionen. Und zu einer Route gehört nun mal eine Richtung. Und eine Option einzuführen, nur weil das Element Route für ganz was anderes missbraucht wird, als das es gedacht ist....? Zumal QMapShack ja Flächen als Element anbietet. Und die haben auch keine Pfeile.

Nimm es mir nicht übel, aber das würde ich lieber bleiben lassen.

Mit der zukünftigen Version 1.3.0 werden die Routen in QMapShack ein wenig Liebe und Beachtung bekommen. Zwar ist der Stand immer noch eher rudimentär, aber immerhin kann man jetzt welche erstellen und berechnen lassen.

Wer nicht warten will muss aktuell den Code selber kompilieren. Oder sich schon mal an der Doku sattsehen:

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

Viel interessanter ist das Autorouting eigentlich beim Track erstellen. Das wurde komplett umgebaut und ist jetzt hoffentlich ein wenig leichter zu verstehen und zu bedienen:

https://bitbucket.org/maproom/…i/DocGisItemsEditMultiple

...ich hätte da noch ein Magellan 610 :p:D

Inzwischen gibt es auch fertige Dateien:

https://jeepxj.de/pub/routino/

Archiv in ein Verzeichnis entpacken und das Verzeichnis beim Routinofenster hinzufügen.

Die muss man aktuell noch selber erstellen:

http://www.routino.org/documentation/usage.html

planetsplitter ist das Tool dazu

Ja, die Geschichte mit Routino funktioniert auch wirklich erst seit diesem Wochenende sauber. Und hat auch mehr im Planungstrack ihren Nutzen.

Mein Problem mit Routen ist, dass ich sie so gut wie nie benütze. Folglich auch nicht weiß, was die Leute erwarten, die Routen verwenden. Im Auto gebe ich ein Ziel an und vertraue dem Navi. Zu Fuß gibt es maximal einen Track als Serviervorschlag, wenn überhaupt.

Dementsprechend karg ist auch noch die Implementierung. Das was in GPX 1.1 definiert ist geht, alles weitere fehlt. Aber so muss es ja nicht bleiben.

Hallo Ralf,

muss ich mal in einer ruhigen Minute ausprobieren.

Wobei QLGT und BRouter derzeit für mich keine Zukunft haben. QLGT ist mehr oder weniger durch QMapShack ersetzt. Und BRouter ist als Java App In einer Nicht Java Umgebung nur als App, nicht als Bibliothek zu verwenden. Ein Versuch BRouter nach C++ zu portieren, habe ich nach Sichtung des Code sehr schnell aufgegeben.

Ich setze aktuell auf Roution. Das ist ein C Programm, kann aber mit wenigen Zeilen Code in eine Bibliothek verwandelt werden. Der Autor von Routino ist der Sache zum Glück sehr aufgeschlossen und hat schon allerlei Änderungen durchgeführt, um den Code für die Verwendung in einer Bibliothek fit zu bekommen. Dadurch, dass es eine Bibliothek ist, kann man in QMapShack jetzt on-the-fly routen, d.h. die Route wird beim Zeichnen gleich angezeigt. Das ist beim Planen von Wanderungen wichtig, weil der schnellste oder kürzeste Weg ist nicht immer der schönste oder sinnvollste ist.

Was die Route als GIS Objekt angeht, ist das alles noch sehr am Anfang. Insofern ein guter Zeitpunkt einzusteigen und Wünsche und Erfahrungen einzubringen. Routino liefert den Wegnamen, die Änderung in Grad und die Richtung in Grad. Daraus sollten sich Abbiegehinweise ableiten lassen. Ich muss noch abgleichen, in wie weit sich so ein Modell auch auf Ergebnisse von MapQuest anwenden lässt.

Routen auf dem Pc hin oder her, Sinn macht das erst richtig wenn man die Route auch auf das Gerät 1:1 übertragen kann. Ob ich das für Garmin hinbekomme steht noch in den Sternen. Ich habe eine Idee, die aber noch auf ihre Erprobung wartet.

Prinzipiell kann QMS Daten für jedes Gerät aufbereiten, bzw die Daten von einem Gerät lesen und in das interne Datenmodell umwandeln. Dazu muss ein Gerätefilter geschrieben werden. Für Garmin und TwoNav habe ich das schon gemacht. Für Android wäre das auch interessant.

Ich könnte mir folgendes vorstellen: Angebunden werden die Androidgeräte über UDP/TCP. Ob das jetzt eine USB Gadget Schnittstelle oder WLan ist, ist dabei egal. Mit UDP werden die Geräte gefunden (pliug-n-play), mit TCP die Daten explizit ausgetauscht. Interessant wäre hier eine App auf dem Gerät, die den Datenaustausch mit QMS regelt und die Daten dann für die jeweilige Kartenapp (Orux, Locus, was auch immer) aufbereitet.

Das wäre etwas Solides, das für jeden bedienbar ist und sich auch sehr einfach auf allen PC Betriebssystemen installieren lässt. Externe Skripten und ihre Interpreter sind für so was eher ein Kreuz.

Das sind Ideen. Da ich Androidgeräte nicht als Ersatz für Outdoor GPS Geräte sehe, werden das von meiner Seite aus Ideen bleiben. Sprich hier muss jemand ran, den das interessiert und der das auch wirklich benützt. Bei der Einbindung in QMS helfe ich natürlich gerne mit Rat und Tat.

Grüße

Oliver

gefixed

gefixed.

Das scheint ein Bug zu sein. Werde ich mir ansehen.

Jetzt funktioniert wenigstens endlich das Routing via Routino.

Zitat von anesthesia

Zur Trackerstellung mittels "V": das mit der Verzögerung beim Einschnappen ist wirklich gewöhungsbedürftig. Vielleicht kannst du da noch was optimieren.

optimiert.

Zitat von anesthesia

Noch eine bitte zum Projektspeichern (also auf der Festplatte): Wäre toll, wenn "Filename" schon per Default ausgewählt wäre - also Dateiname ist gleich Projektname.

ok

Zitat von anesthesia

Hinzufügen von Trackpunkten: beim Abspeichern ("Ins Original speichern)" erfolgt folgende Meldung - siehe track.jpg - ist aber überflüssig und verwirrend, da die Trackpunkte eh hinzugefügt wurden.

Aber auch nur bei einem komplett neuen Track. Wird ein existierender Track geändert, kann tatsächlich Information verloren gehen. Deswegen ist die Warnung wichtig.

Alle Änderungen sind im Repo.

trailsucher@vm-mate172 ~/QMapShack $ hg clone https://bitbucket.org/maproom/qmapshack serverdaten
Fordere alle Änderungen an
Füge Änderungssätze hinzu
Füge Manifeste hinzu
Füge Dateiänderungen hinzu
Fügte 1039 Änderungssätze mit 6769 Änderungen an 1432 Dateien hinzu (+2 Köpfe)
Aktualisiere auf Zweig default
[B] Abbruch: 'svn' executable not found for subrepo '3rdparty/Routino'[/B]

subversion installieren.

Komisch. Ich kann ohne Probleme Projekte mit dem selben Namen anlegen.