Ach klar, den GPS Status hatte ich auch schon gesehen, nur wird der leider nicht mit aufgezeichnet. Um genau zu sein: der zeigt kein DOP, sondern eine metrische Fehlerangabe (keine Ahnung was das ist, vielleicht CEP?), differenziert auch nicht zwischen HDOP und VDOP (Höhen-/Horizontalfehler). Die Höhe ist ja immer das größere Problem in GPS. Ich verstehe nicht, warum DOP bzw. CEP. nicht einfach in das GPX-Log eingebettet wird. Neben der eigentlichen Koordinate ist das für mich schon eine wichtige Angabe, vor allem wenn Geodaten automatisch verarbeitet werden.
Wie war denn im obigen Fall die Laubsituation? Ich habe an den meisten Stellen im Wald auch noch relativ guten Empfang, oft aber auch extreme Abweichungen, an einigen Stellen im Vorgebirge sogar ziemlich verhexte schwarze Löcher, wo ich immer total den GPS Fix verliere (ohne Bergabschattungen, so als ob da jemand einen Störsender betreiben würde). Vielleicht war auch gerade zufällig die Sat-Konstellation ungünstig (komischer Zufall, immer wenn ich zufällig im gleichen Waldstück bin …).
Übrigens spuckt mein Qualcomm gpsONE Chipset tatsächlich NMEA scentences aus. Ich dachte schon die hätte man wegrationalisiert, weil ich die in Android nirgendwo gesehen hatte. Aber Android hat sogar eine API dafür spendiert: “android.location.GpsStatus.NmeaListener”. Ich kannte es nur von früher (zu SIRF-Zeiten), wo NMEA über einen seriellen Port ausgelesen wurde.
Gerade habe ich den “NMEA Recorder” ausprobiert. Tatsächlich ist viel NMEA drin, GPGSV, die DOP-Werte etc.
Schade nur, dass die GPS-Aufzeichnung in den Karten-Apps (OsmAnd, Orux, Locus) das nicht können. Die Multiplex wird zwar funktionieren, dass 2 Apps gleichzeitig auf GPS zugreifen (die KArten App und der Recorder), aber das geht natürlich wieder auf die Akkulaufzeit.
Ich hatte gelesen, dass es in diesem Forst einen ziemlich radikalen Förster gibt, der haufenweise Wege mit Baumstämmen absperrt, die von den Bürgern schon jahrzehntelang genutzt wurden. Sollen die jetzt alle auf den kilomenterlangen schnurgraden asphaltierten Waldpisten laufen? Wofür geht man denn in den Wald, wenn man keinen echten Waldboden mehr unter die Füße bekommt? Für Wildtiere gibt es immer noch genügend Rückzugsgebiete, aber der Wald ist ja auch für Menschen da. Es gab große Proteste von Bürgern, die da schon seit Jahren mit ihrem Hund spazieren gehen. Das Argument dass Leute mit ihren Füßen oder Radfahrer-Rowdies den Boden kaputt machen ist doch lächerlich: derjenige der wirklich den Boden kaputt macht ist der Förster selbst mit seinem Angeber-Geländefahrzeug. Und solche SUVs machen richtig krach im Wald, nicht die Spaziergänger.
Sollten wir es dem Förster leicht machen und die Wege gleich eleminieren. Oder gehen wir mit den Bürgern und lassen die erstmal drin? Man könnte sich einen Kompromiss überlegen: man lässt die Wege drin, solange sie gut passierbar sind und mappen einfach nur die Baum-Barriere. Der resolute Bürger geht sowieso um die Baumstämme herum. An deren Stelle würde ich auch auf das Gewohnheitsrecht beharren. Irgendwie muss man doch protestieren. Wenn die Politiker-Schlappschwänze den Bürgerwillen nicht umsetzen muss man eben mit Füßen abstimmen.
Oh, dann hatte ich wohl an der falschen Stelle gespart, die Freeware kann es nicht …
Aber nutzt nichts, wenn das nicht im Recording steht. Ich werd mir nicht auf Papier notieren, wo der Track gut oder schlecht war. Am einfachsten wäre es wohl, den OsmAnd Sourcecode zu patchen, um die Werte dem GPX-Logfile hinzuzufügen.
p.s.:
bei NMEA kann man die schlechten GPS-Punkte mit gpsbabel einfach herausfiltern.
Meist ist es zwar offensichtlich (am gezappele), aber oft hatte ich den Fall (Gebirge), dass
der Track langsam weggedriftet war, so als ob man einen anderen Weg gehen würde.
Die DOPs hatte ich daher bei den alten GPS-Geräten immer mitgeloggt (alle NMEA-sentences im Logger aktiviert).
ne, dass die das zum import freigeben, so meinte ich das. wer das macht ist mir auch klar … sorry ich drück mich öfters so aus das nicht alle gleich mitkommen
Ich nutze auf meinem Smartphone GPSLogger und OSMTracker für Android. Eine der beiden Apps speichert im GPX-Track auch einen DOP-Wert. Diesen DOP-Werte kann man sich in JOSM dann als Kreise um die Trackpunkte anzeigen lassen (muss man in den Eigenschaften des GPX-Layers einschalten).
Wenn ich GPS-Tracks aufzeichnen will, nehme ich jedoch immer noch meine Garmin Dakota 20, da der mit einer Akkuladung deutlich längere Tracks aufzeichnen kann und auch einen besseren GPS-Chip als mein LG Optimus Speed P990 hat.
Ich persönlich habe ein paar dieser Wanderrouten nur zum Vergleich mit den entsprechenden in OSM genutzt und die bei OSM öfter mal vorhandenen Lücken oder Verlaufsabweichungen dann vor Ort geklärt.
Um mit Forest Gump zu antworten:
“Das Leben ist wie eine Pralinenschachtel, man weiß nie, was drin ist.”
Garantien gibt es keine, aber höchst unwahrscheinlich ist es dennoch.
[Umrisse erkennen]: Microsoft hat so etwas mal für Luftbilder entwickelt, mit nur Schwarz und Weiß sollte das gut funktionieren, wenigstens für alleinstehende Gebäude. Der viel interessantere Fall “Wand an Wand” wird wohl deutlich schlechter funktionieren. Und bei dem Fall, dass das mittlere von drei Häusern auf zwei extraschmalen Grundstücken steht, wird es wohl endgültig versagen.
Viel interessanter fände ich die Möglichkeit, Nummern zu extrahieren, zum Beispiel automatisch die Höhenangaben zu finden.
Auch wenn ich damit vom eigentlichen Thema ziemlich abweiche, ein Kommentat zu dieser Aussage:
Ich nutze mehrere GPS-Logger gleichzeitig und kann dadurch Ausreisser ziemlich gut identifizieren (es machen nie alle gleichzeitig Seitensprünge und wenn unvermeidlich (Tunnel), nie gleichartig). Nach meiner Erfahrung sind VDOP und HDOP nur bedingt als Qualitätsanzeiger geeignet. Das sind Werte, die die Firmware formal berechnet, die aber nur wenig mit tatsächlichem Fehlerbereich zu tun haben. Als besserer Indikator hat sich die Höhe herausgestellt. Es gibt keinen geometrischen Grund, weshalb die Höhe schlechter sein sollte als die horizontalen Werte. Sie wird nur längst nicht so stark durch die Firmware geglättet wie die horizontalen Koordinaten. Wenn es da unmotivierte Höhenänderungen gibt, ist fast immer auch der horizontale Track auf Abwegen.
Es lohnt sich also, einen Blick auf die Höhen zu werfen, die DOP-Werte haben bei mir ausgedient.
Bei einem automatische Import egal ob per Datei oder per Vektorisierung fehlt gerade der Mensch als Filter. Ich bezweifle z.B. ein wenig, dass die frei verfügbaren Katasterdaten in NRW die tagesaktuellen Daten sind. Für die muss man nämlich in der Regel zahlen.
Bei Maps4W hinken die Gebäudeumrisse, da wo ich es überprüfen kann, um ein bis drei Jahre hinterher.
Die Variante mit dem Reitweg ist mir neu. Gut, dass der Weg wenigsten weiter genutzt wird. Ich muss mir das also nochmal ansehen.
Die Reiter haben es im Kottenforst mit einem allgemeinen Reitverbot auf nicht explizit gekennzeichneten Wegen sowieso schwer.
Ich bin bei meiner Besichtigung bis zu der Stelle gegangen, wo der Einschnitt abgeht (bei der 162m Höhen-Marke). Es war mir aber zu unsicher, ob man da noch irgendwo hin kommt und so bin ich lieber umgekehrt.
Einen Punkt möchte ich noch ansprechen:
Laut Key:ele stehen in ele=* Höhenangaben nach WGS84. Das macht natürlich keiner. Deswegen habe ich mir direkt angewöhnt, alles was ich aus der DGK5 entnehme mit ele:DHHN92 [1] als Schlüssel einzutragen. Dann ist wenigstens klar, auf welches Referenz-System ich mich beziehe. Ich möchte allen Mappern empfehlen das Gleiche zu machen. Ansonsten stehen (wie bereits heute) Werte nach allen möglichen Referenz-Systemen ununterscheidbar im Tag ele. Einen Wert nach WGS84 würde ich konsequent mit ele:WGS84 erfassen.
[1]: DHHN92 bedeutet Deutsches Haupt Höhen Netzwerk 1992. (Wichtig: Zwei “H” ein “N”.)
Den Bergmannspfad sollte man ruhig lassen, wie er ist. Einerseits ist die frühere Schneise noch gut zu erkennen, andererseits ist er ohne erkennbare Beschränkung in der DGK5 und auch der DTK10 enthalten und würde daher regelmäßig wieder auftauchen. Bei uns sieht man wenigstens, dass der Weg nicht mehr benutzt werden soll/kann/darf.
[OT]: Heute habe ich eine schicke Erkundungstour gemacht. Unter anderem bin ich meinen ersten Weg gegangen, der damals noch nicht eingetragen war (ich muss noch ein wenig daran feilen). Zum Schluss bin ich mit dem Rad eine schöne, enge, steile Strecke gefahren, bei dir ich früher mal wegen Begleitung das Rad runter schieben musste.
Na, was heißt empfehlen? Das ist Pflicht, falls von WGS84 abweichende Systeme benutzt werden. Ansonsten wäre das eine Falschinformation. Bestenfalls darf man noch “ele:local=” schreiben, was sich auf das “lokale” System bezieht, bei uns eben das DHHN92. Für die automatische Auswertung ist das schon wichtig, damit die Werte entsprechend Normalisiert werden können, z.B. für 3D-Karten. Aber dafür ist vermutlich noch zu wenig Höhe getaggt, oder? Wenn das zu lückenhaft ist muss man dann doch auf externe Quellen wie STRM zurückgreifen.
Ok, du meinest also eine Touren-Sammlung. Das muss vom “offiziellen” Wanderwegenetz unterschieden werden, das vor Ort ausgeschildert wird. Manche Touren gehen zwar entlang dieser Wanderwege, aber es gibt eben auch viele andere Tourenvorschläge abseits dieser Wege. Die werden sicherlich auch nicht alle auf der normalen Topo-Karte erscheinen. Dazu gibt es dann redaktionell bearbeitete Spezialausgaben wie die “Traumpfade”,mit Sonderkarten dafür.
Mit Übernahme in OSM hatte ich vorhin ausschließlich die offiziellen Wanderwege angesprochen. Die sind gut geeignet zur Produktion von OSM-Wanderkarten. Ich denke wenn man OSM als Tourendatenbank ausbaut wird das schnell sehr unübersichtlich mit den vielen Relations. Und bei Tourenportalen wie Gpsies.com ist auch viel Müll drin, den ich in keiner Karte sehen möchte. Da läd ja quasi jeder Freizeitjogger seine Privattouren ab. Ob die von Allgemeinem Interesse sind, naja. Natürlich gibt es da auch schöne Touren. Bei der Masse dort sind die aber schwierig zu finden.
Prinzipiell wäre es natürlich eine schöne Idee, ein Tourenportal auf OSM-Basis auf die Beine zu stellen. Ein einfacher Overlay geht natürlich immer. Aber wenn die Touren auf OSM-Objekte bauen sollen, stelle ich mir die Datenbankkopplung schwierig vor.
Ich haber auch noch einen kleinen GPS-Logger, mit besserem Chip. Nur AGPS hat er nicht, ist also nicht so schnell Betriebsbereit wie das Handy. Manchmal hab ich dann auch 2 Geräte mit, aber meistens ist es mir doch zu lästig.
In den Bergen korrelieren die Fehler aber doch oft. Das liegt dann einfach an der Abschattung und an Reflexionen. Davon sind dann alle GPS-Empfänger gleichermaßen betroffen. Die Kalman-Filter können u.U. bei schlechtem Empfang auch mal in verschiedene Richtungen abdriften.
Natürlich sind HDOP, VDOP, PDOP und GDOP noch keine endgültige Aussage über die Qualität. Die sagen erstmal nur etwas über den geometriebedingten Fehler aus, über die zu erwartende Varianz-Erhöhung bezüglich Varianz einer einzelnen Pseudorange-Bestimmung. So kann man dann auch wieder auf metrische Einheiten kommen. Was DOP aber nicht ausdrückt sind Fehler der Pseudorange-Messung selbst, also Multipath, schwache verrauschte Signale. Solche Fehler kann der Chip auch schlecht abschätzen. Die Meter-Angabe in GPS-Status ist daher vermutlich auch nur ein HDOP, der mit einem Default-Wert für den üblichen Pseudorange-Jitter multipliziert wurde. Was neben DOP noch hilft sind die SNR-Angaben zu den Sat-Signalen. Mehr Zuverlässigkeits-Infos wirst du da nicht herausbekommen.
Die Höhe ist meist aber doch schlechter aufgelöst. Das liegt an der Geometrie. Wenn alle Satelliten in einer Ebene liegen würden, könnte man die Höhe so gut wie überhaupt nicht mehr bestimmen. Die Matrix der Pseudoinverse in der Navigationsgleichung bekommt dann einer sehr schlechte Kondition. Die Sats verteilen sich nun auf einer Fläche einer Kugelschale auf einem 20000km-Orbit. Die ist natürlich etwas krumm, was dann eine gewisse Höhenbestimmung ermöglicht, aber doch noch eher flächig, da Satelliten niedriger Elevation nicht mehr zu empfangen sind. Das hängt aber von der momentan-Konstallation ab. Meist ist der VDOP so aus geometrischen Gründen schlechter. Die Diskrepanz zwischen HDOP und VDOP wird noch größer in hohen Breiten, weil die GPS-Orbits nur um 55° inkliniert sind, also noch weniger Sats überm Kopf fliegen, um die 3. Dimension aufzuspannen. Zum Glück sind solche Geometriefehler gut berechenbar und daher auch die DOP als solche sehr exakt. Was bei der Höhe noch dazukommt: die Beulen der Erde im Vergleich zum WGS84-Referenzellipsoiden. Der Ellipsoid ist dank dem Internationaler Erdrotationsdienst gut bestimmt. Die Beulen der Erde müssen aber separat kartiert und kompensiert werden.
