Beiträge von kiozen

Zitat von xbiker

Ich habe uebrigens 2 Tickets auf gemacht wie mir geheissen.

Eines ist schon wieder zu

Du meinst wahrscheinlich das Mapsforge Format. Das ist aber leider nun wirklich keine Alternative. Sondern eine Notlösung, wie ich Kacheln on-the-fly rendern kann, weil ich sie im großen Stil nicht vom Server saugen darf. Das Format ist immer noch reichlich groß, die Polylinieninformation beschränkt sich auf Segmente in 256x256 Kacheln. Außerdem müsste man entweder alles mit Java machen oder solche Bibliotheken wie mapnik nach C++ portieren.

Viel Arbeit für ein Vektorformat, dem die Vorteile eines Vektorformates fehlen. Das funktioniert nur bei Java- basierenden Geräten mit einem reichlich starken Prozessor und viel Speicher. Und zum Routen brauchst Du dann nochmal extra Daten. Das ist für mich jetzt nicht das Gelbe vom Ei.

Oder benutzen den U-Blox Chipsatz weit unter seinen Möglichkeiten. Dazu hatte ich letztes Wochenende einen sehr interessanten Besuch. Aber das ist offtopic..

Ich glaube Garmins Format zu übernehmen ist ein no-go. Garmin ist in der Beziehung sehr tolerant. Aber wenn ein Konkurrent das Format übernimmt, dürfte Schluss mit weich und kuschelig sein.

Irgendwie schade dass Compe hier nicht die offensichtlichen Chancen sieht.

Naja, wenn dann müsste Compe schon seine Tools zur Verfügung stellen. Soviel ich weiß sind die Vektorkarten von Compe anders, als die die CompeLand erstellen kann. Oder habe ich das falsch im Kopf?

Ich sehe schon ein, dass OSM Karten erstellen für eine Firma eher lästig ist. Aber dann muss man eben einfach ein wenig die Hosen herunterlassen und die Sache abgeben. Ich könnte mir vorstellen wenn freizeitkarte.de die Karten auch noch im Compeformat anbietet tut das nicht weh, sondern ist Werbung.

Warum gibt das Compe eigentlich nicht an die Community ab? Ich mein sogar der hochgradig paranoide Laden von Magellan macht das. Dort muss zwar die Software zum Erstellen von Karten immer über Netz mit dem Hauptquartier kungeln, damit theoretisch die Reißleine gezogen werden kann. Aber immerhin gibt es so aktuelle Karten für kleines Geld. Eigentlich kann bei so etwas doch nur jeder gewinnen, oder?

Zitat von xbiker

Ich haette es nicht erwaehnt und fuer ein pers. Problem gehalten, waere es mir nicht auf beiden Rechnern so ergangen.
Egal, wird spaetestens nach einem Neustart wohl gehen.

Das glaube ich Dir. Insofern wäre es gut zu wissen woran das liegt. Du kannst;

1) Sämtliche Kartenpfade entfernen: Datei->Kartenverzeichnis angeben
2) Das Verzeichnis C:\Users\<benutzer>\.QMapShack entfernen
3) Die *tms Dateien aus dem Kartenverzeichnis entfernen.

Jetzt ist der ursprüngliche Zustand wieder hergestellt. Und dann versuch es nochmal. Irgendwas muss anderes sein.

Zitat von xbiker

Ja, am ganzen Projekt, nicht an den einzelnen Tracks. Ich habe da temporaer immer Trackschnipsel rumliegen, auch ueberlagernd (Kopie, Teilkopie, Teilkopie_rev, etc..). Da waer's handlich ein paar schnell wegblenden zu koennen. Ich raeume hinterher auf, wenn mein Komplettrack fertig ist.

Das würde aber bedeuten, dass man für jedes Element eine Checkbox hat. Ich finde das sieht schon bei der Datenbank furchtbar unübersichtlich aus. Die Projektansicht hätte ich gerne weiterhin etwas aufgeräumter.

Ich benütze beim Planen immer mehrere Projekte, aus denen dann Teile in das Zielprojekt übertragen werden. Da der Projektname bei der Anzeige angehängt wird verliere ich nicht den Überblick.

Zitat von xbiker

Ich mache mal ein paar Screenshots um meine typischen Problemstellungen zu verdeutlichen. Vielleicht geht das ja auch mit dem jetzigen Funktionsumfang anders gut und ich weiss nur nicht wie?

Das Problem ist mir schon klar. Nur sollte es jemand ordentlich machen. In QLGT habe ich solche Wünsche ad-hoc immer erfüllt. Gedankt wurde es selten. Oft habe ich Monate später Bugs gefunden. Sprich es wurde nie genutzt. Und weil das alles immer nur ad-hoc gemacht wurde, wuchs der Code zu einem Moloch, ohne Konzept, der zum Schluss einer vernünftigen Lösung im Weg stand.

Deswegen würde ich jetzt erst mal gerne sehen, dass auch erweiterte Datenfelder eingelesen und wieder geschrieben werden können. Und dass das Datenmodell vom Track so flexibel ist, damit sich jedes Datenfeld in Form eines Graphen anzeigen lässt. Der Schritt zur Kolorierung ist dann ein vergleichsweise kleiner.

Da das alles weit außerhalb meines eigenen Bedarfs liegt, ist mein Interesse daran gering. Deswegen ist es besser es findet sich jemand, der es wirklich braucht. Aber auch hier gilt: Ein Issue aufmachen, dann gerät es nicht in Vergessenheit. Nur so besteht immerhin eine Chance, dass sich jemand findet. Interessanterweise gebe ich diesen Rat recht oft. Ein Issue, in einer brauchbaren Form, wird selten geöffnet. Offensichtlich sind die meisten Wünsche es den Benutzern dann doch nicht wert Womit wir wieder beim zitierten Rüffler wären Ohne eine gewisse Eigenleistung von jedem funktioniert OpenSource auf Dauer nicht.

Zitat von xbiker

ch habe auf 2 Rechnern (beide Male W7 64bit) QMS frisch installiert und sogleich "Ich will Karten" gedrueckt. Daraufhin werden ein paar Online-Karten angelegt, aber zunaechst passiert erstmal nichts. Auch nicht, wenn ich die Karten aktiviere. Erst nachdem ich das Kartenverzeichnis erneut gesetzt habe scheint QMS es richtig verstanden zu haben und dann werden nach Aktivierung einer Onlinekarte auch Kacheln geladen.
Kein grosses Ding, mag einen Neuling aber vielleicht erstmal stutzen lassen?!

Ich habe es gerade ausprobiert. Ich bekomme die Liste der Karten, wähle die OSM Karte aus und bekomme sofort was angezeigt.

Zitat von xbiker

Der Datenbankimport aus QLGT hat einwandfrei geklappt - super. Ich benutze die Datenbanktextdatei gerne um alle meine Trackdaten auf der Speicherkarte meines Garmins mitzunehmen. Bin ich dann an einem anderen Rechner, kann ich dort planen und die geaenderte Datenbankdatei wieder mitnehmen und zuhause einspielen. Ich hoffe QMS ist da genauso gnaedig, wenn man hintenrum einfach Datenbankfile austauscht!?

So gnädig wie SQLite ist. Ich hoffe da kommt es nie zu Problemen wegen unterschiedlicher SQLite Versionen. Und natürlich können verschiedene Versionen von QMS die Datenbank zerschießen. Ich achte darauf, dass neue Versionen ältere Datenbanken auf auf den neuen Stand bringen. Andersherum nicht.

QMS kann jetzt auch mehrere Datenbanken laden. So kann man Daten aus Tourenführern von den eigenen trennen.

Und man kann, die meisten wissen es nicht, QMS (und auch QLGT) mit einer Konfigurationsdatei starten (https://bitbucket.org/maproom/…ck/wiki/DocGettingStarted). D.h. man kann QMS auf der SD Karte ablegen, und über eine Verknüpfung mit der Konfiguration starten, so dass alles auf der SD Karte abläuft. Man ist damit komplett autark und benötigt nur einen PC mit Windows. So der Plan richtig ausprobiert habe ich es mit Windows noch nie.

Zitat von xbiker

Das Ueberlagern verschiedener Karten klappt gut und intuitiv. Nicht ganz logisch erscheint mir welche Karte im Kartenstapel welche ueberlagert. Meine spontane Erwartungshaltung waere gewesen, dass sich die Karten wie uebereinanderliegende Folien verhalten, also eine obenliegende Vektorkarte eine untenliegende Satellitenkarte ueberdeckt. Bei QMS ist es nun genau umgekehrt (untenliegende Karte "toppt" obenliegende), was nicht schlimm ist wenn man's weiss, aber vielleicht auch andere zunaechst verwirrt?!

Naja, das ist wirklich Ansichtssache. Für mich ist das eine Liste, die von oben abgearbeitet wird. Da plötzlich umzudenken finde ich unlogisch. Aber ich finde auch die Mausradrichtung, wie sie Google einem aufoktroyiert reichlich unlogisch. Vielleicht gibt es ja rechts und linksdrehende Gehirne.

Zitat von xbiker

Ziemlich cool ist auch die Moeglichkeit mehrerer Views. Meiner Art zu planen wuerde es mehr entsprechen, wenn "Kartenansicht hinzufuegen" nicht eine neue, leere Ansicht erzeugen wuerde, sondern gleicht die aktuelle Ansicht duplizieren wuerde. Ich merke halt erst waehrend meiner Planung, dass ich jetzt schon 2x hin und hergescrollt habe und eine weitere Ansicht nuetzlich waere, und dann habe ich gerade eine brauchbare Ansicht eingestellt, koennte diese duplizieren und von dortigen Gegebenheiten aus veraendern. Geht ja, via Kartenansicht speichern und dann laden, allerdings ueber den Umweg der Erstellung einer Datei, die ich spaeter nicht mehr brauche.

Ok, die bisherige Idee war unterschiedliche Karten in jeder Ansicht zu haben. Obwohl das über drag-n-drop in der Liste eigentlich einfacher geht. Mach halt ein Issue auf, dann wird die Idee nicht vergessen (https://bitbucket.org/maproom/qmapshack/wiki/BugFeatures)

Zitat von xbiker

2 Dinge fehlen mir derzeit etwas:
#1 schnelles Ein-/Ausblenden von Tracks im Workspace.
Oft verdeckt der Track den darunterliegenden Weg und ich moechte gern schnell nachgucken, ob und was fuer ein Weg da wirklich drunter ist. Vielleicht habe ich es nur noch nicht gefunden?! In der Datenbank geht das, ist aber bei mir oft mit Scrollerei verbunden, weil die DB schon reichlich Eintraege hat. Waere schoener, wenn's im Workspace auch ginge.

An jedem Projekt im Workspace ist eine Checkbox mit der sich der Inhalt des Projektes verstecken lässt.

Zitat von xbiker

Was fuer mich am allerbesten funktioniert hat war das einstellbare Multi-Colouring eines Tracks in Abhaengigkeit der Neigung. Hier konnte ich zwar nicht sehen ob's rauf oder runter ging, aber das hat mir sehr schnell und zuverlaessig angezeigt, welche Bereiche meiner Strecke signifikant anders als gerade waren (und WIE anders sind sind).

Oh, Du hast das wirklich benutzt? Das war bisher nach meiner Sicht eines der unnützen Features in QLGT. Insofern ist da nichts in Planung. So wie es in QLGT gelöst ist gefällt es mir auch nicht, weil für jeden Wert extra Code geschrieben werden muss. Und das nicht zu knapp. Wenn jetzt noch jemand kommt und Erweiterungen im Track benutzt, wie z.B. die Temperatur von Transplantationsorganen oder die natürlichen Strahlung, wird es richtig wild. Sprich man müsste eigentlich die Trackdaten sehr flexibel erweitern können und dann auf diese Daten jeweils die Kolorierung ansetzen. Aber das ist aktuell überhaupt nicht in meinem Focus. Das soll machen, wer wirklich Nutzen daraus zieht.

Soviel ich weiß ist es ein TESEO 208 MHz – STA8088EXG, also ein SoC.

Hat schon jemand herausbekommen, ob auch ein etwas stärkerer Prozessor in den neuen Geräten verwendet wurde?

Ausgehend von dem Aha-Erlebnis mit dem S5mini im Winter habe ich seitdem jeden mit einem Smartphone genervt, ob ich mal bei praller Sonne mit einer Sonnenbrille aufs Display schauen darf. Das war alles sehr ernüchternd. Anderseits was will man von einem Display erwarten, das von sich aus leuchten muss, damit man etwas erkennt? Mit welcher Beleuchtung will man ernsthaft gegen die Sonne anstinken? Und wenn, zu welchem Preis bezogen auf die Akkulaufzeit?

Sicher kann man an der Lichtdurchlässigkeit und dem Wirkungsgrad der Beleuchtung optimieren. Aber es wird immer schlechter sein, als ein transreflektives Display. Genauso wie andersherum das transreflektive Display nie an die Auflösungen der in den Smartphones verwendeten Displays herankommen wird.

Ob das Display vom eTrex von der Größe akzeptabel ist oder nicht, muss man selber entscheiden. Ich komme mit dem nur etwas größerem Display vom 62er prima zurecht. Bei Garmin kann man alle Karten einfach an und abschalten und auch übereinander legen. Wobei das selten Sinn macht. Man schaut eh nur auf die in diesem Gebiete beste Karte.

Weil es angesprochen wurde: Die DAV Karte gibt es auch für die Garmins. Die ist natürlich verglichen zu dem was OSM in den Bergen anzeigt besser. Diese Karte ist ein Hybride aus Vektor und Rasterkarte. Der Preis für Alpenvereinsmitglieder so fair, dass ich mich nicht stundenlang hinsetzen werde, um mir irgendwas Vergleichbares aus dem Netz zusammenzufrickeln. Wie Gerhard schon schreibt: Anschalten und losgehen.

oha, den Null Pointer sollte man abfragen. Habe ich ausgebessert. Vielen Dank fürs Finden.

Aber probiere auch mal QMapShack aus. Das ist die Zukunft.

Die Alpenvereinskarten haben zum Teil wirklich starke Fehler. Zum Teil basieren die auf Daten aus den 50er Jahren. Um die richtig hinzuziehen benötigt man viel Erfahrung. Für die Garmin Geräte hat das jemand gemacht. Auf der SD Karte sind alle Blätter drauf. Gut, bringt jetzt ohne Garmin Gerät oder Hacken nichts.

Ich darf mich nochmal selbst zitieren:

Zitat von kiozen

In die Datei

Code

/etc/modprobe.d/50-blacklist.conf

habe ich am Ende

Code

blacklist garmin_gps

geschrieben. Und in

Dann wird garmin_gps auch beim nächsten Reboot nicht geladen.

Aufgrund der des Suffix "CSx" glaube ich ja eher dass der Kollege sich bei der Nummer verschrieben hat und ein 60er besitzt

Bei Tages Etappen kann man übrigens in QLGT Wegpunkte auf den Track platzieren lassen, diese anpassen indem man sie verschiebt. Und dann den Track an diesen Wegpunkten teilen lassen.

In QLandkarte GT gibt es einen Trackfilter mit dem man einen Track in Teilstücke zerlegen kann.

http://qlandkarte.org/

* Die GPX Datei mit dem Track laden
* auf den Reiter mit den drei *** gehen
* Track mit der rechten Maustaste auswählen, im Menü "Bearbeiten" auswählen

Es erschient ein Dialog mit allerlei Optionen. Dort gibt es einen Reiter "Filter" und in der Ansicht wieder einen Reiter "Teilen". Drückt man die Knöpfe mit dem Zahnrad, wird der jeweilige Filter auf den Track angewendet.

Zitat von papaluna

1.Höhenmeter:
auch ich habe immer wieder gewisse Abweichungen zwischen diversen Geräten(Anima, Ultra, Suunto, Ciclo) festgestellt.
Soweit ich das noch feststellen kann sind die Unterschiede bei Anima, Ultra < 10% gewesen.
Welcher der bessere/richtigere Wert war, läßt sich halt nur schwer ermitteln. Mam müßte halt die Möglichkeit haben die Geräte ein vermessene Höhe hoch/runter zu bewegen.

Hierzu reicht in der Regel ein Hügel in der Nähe. Wichtig ist, dass der Weg immer aufwärts geht. Dann kann man die Höhendifferenz aus den DEM Daten nehmen.

Mein Testhügel ist z.B. hier: N49° 01.577 E012° 15.427 Mit garantierter Steigung bis nach oben.

Zitat von papaluna

1.1 Entfernungen
gerade mal nachgeschaut: bei 82,47km(Anima) vs. 83,00(Ultra) verschwende ich keinen weiteren Gedanken dran.
Bzgl. des Sensors beim ANIMA+ kann ich nichts sagen. Eine korrekt eingestellter Radumfang ist aber generell wichtig.
Wobei ich nicht weiß,
Wird der Enfernungs/Distanzwert zwischen 2 Punkten auf Basis des Sensors gespeichert und gegebenfalls auch zur Berechnung der Distanzen z.B. in CGPSL genutzt?
Ansonsten erfolgt die Distanzmessung ja über die GPS-Koordinaten und ist vom Reifenumfang unabhängig.

Alles anzeigen

Man sollte vielleicht auch mal ein wenig die Genauigkeit der Stellen betrachten. Keine Stelle hinter dem Komma kommt auf einen Rundungsfehler von max. 500m. Bei 20km sind das 2.5%.

Wenn ich 20km/h fahre, also 5.6 m/s und alle 3 Sekunden aufzeichne, komme ich auf 16.8 m. Nehme ich mal bei der GPS Position einen statistischen Fehler von 1m an, ist der maximale Fehler in einem solchen Intervall schon 5.9%.

Über die Gesamtstrecke werden sich diese Fehler teilweise wieder heraus mitteln. Sprich ganz so mies wie 5.9% wird es nicht werden. Aber ich würde auch kein deutlich besseres Ergebnis als 2.5% erwarten. Also ist eine Differenz von 500 Metern durchaus realistisch.

Das ist eine Betrachtung bei 3s. TwoNav zeichnet im Automodus aber sehr viel öfter auf. Damit ist das Intervall zwischen den Messpunkten kleiner und der statistische Fehler wiegt schwerer. Das können im Dunstkreis von 20km schon mal 1-3 Kilometer sein, die der Track abweicht. Nach dem Ausdünnen sollte der Wert aber wieder halbwegs im <1km Unterschied liegen.

Zitat von kiozen

"%1.2f" bedeutet zum Beispiel 2 Nachkommastellen. Wenn jemand einen guten Vorschlag für eine andere Tabelle hat und niemand "Nein" brüllt, kann ich das gerne dann abändern.

Nochmal zur Erinnerung: Das ist OpenSource. Und nicht das Wunschkonzert des Bayerischen Rundfunks. Wenn Du was geändert haben willst, dann beteilige Dich und biete was Sinnvolles an.

Zitat von meute

Kann man die Länge mit 1-2 Nachkommastellen schreiben?
Gerne auch als Einstellung in der Software. Dann kann es sich jeder User anzeigen lassen wie er will.

Die Nachkommastellen werden automatisch umgestellt. Kurze Strecken mit zwei, lange mit einer. Ich bin kein Freund von ellenlangen Optionsdialogen. Viel Arbeit und die meisten Benutzer haben keinen Bock sie zu verstehen. Aber über die Grenzen was lang und was kurz ist, könne wir gerne diskutieren. Die sind aktuell eher zufällig gewählt:

void CUnitMetric::meter2distance(qreal meter, QString& val, QString& unit)
{
    if(meter == NOFLOAT)
    {
        val  = "-";
        unit = "";
    }
    else if(meter < 10)
    {
        val.sprintf("%1.1f", meter);
        unit = "m";
    }
    else if(meter < 1000)
    {
        val.sprintf("%1.0f", meter);
        unit = "m";
    }
    else if(meter < 10000)
    {
        val.sprintf("%1.2f", meter / 1000);
        unit = "km";
    }
    else if(meter < 20000)
    {
        val.sprintf("%1.1f", meter / 1000);
        unit = "km";
    }
    else
    {
        val.sprintf("%1.0f", meter / 1000);
        unit = "km";
    }
}

"%1.2f" bedeutet zum Beispiel 2 Nachkommastellen. Wenn jemand einen guten Vorschlag für eine andere Tabelle hat und niemand "Nein" brüllt, kann ich das gerne dann abändern.

Zitat von meute

Kann man zwei Längen angeben?
Also die räumliche Länge (3D-Länge) und die horizontale Länge (2D-Länge)?

Die 2D/3D Diskussion bezüglich der Länge hatten wir hier schon in diversen Formen. Der Unterschied ist in der Regel so gering, dass eine unterschiedliche Auswertung keinen wirklichen Sinn macht.

Die Trackinfo ist schon genug überladen. Da würde ich das nicht gerne haben. Wenn es jemand mal programmieren will, dann kann das in die Blase, die einen Bereich angibt. Aber auch dort ist die Information eher überflüssig. Wenn es so steil wird, dass sich langsam ein nennenswerter Unterschied abzeichnet, rechnet man bei der Tourenplanung eh nicht mehr in Distanz sondern in Höhenmetern.

Version 1.2.1 ist inzwischen draußen.