Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

openzzz · 2013-10-27 10:53:00

toc-rox wrote:

EvanE wrote:
Profigräte verwenden zwei Bänder und etliche Korektur-Dienste und kommen damit auch im Wald auf deutlich besser als 1m Genauigkeit.
Ich hatte mir zuletzt noch einen GPS-Referenzpunkt einmessen lassen. Lagegenauigkeit: 1.6 cm; Höhengenauigkeit ca. 4 cm
openzzz wrote:
Früher in NMEA-Recordings hatte ich wenigstens noch die DOP-Werte drin, dass man wusste wie schlecht es ist. Heutzutage in den Smartphones gibt es meist nur noch GPX-Tracks ohne Integritäts- und Genauigkeitsdaten.
Die App "GPS Status" zeigt die aktuellen DOP-Werte. Desweiteren gibt es im App-Store mehrere Programm die die NMEA-Werte aufzeichnen (mal nach NMEA suchen).
Gruß Klaus

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.

openzzz · 2013-10-27 11:11:20

chris66 wrote:

EvanE wrote:
Die Wattendorfer Allee (Kottenforst Richtung Pecher Straße / L158) ist seit Jahren nicht mehr mit der L158 verbunden, sie endet einfach im Wald. In OSM ist das noch falsch, in der DGK5 ist das richtig eingetragen.
Dort ist es als Reitweg eingetragen der kurz nach der Wegkreuzung abbiegt. So hab ich's nun in OSM eingetragen.
Der folgende Weg sollte evntl. gelöscht werden (laut "note" wurde er renaturiert) :
http://www.openstreetmap.org/browse/way/66461915

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.

wambacher · 2013-10-27 11:29:35

Chenshi wrote:

ich meinte die behörden/vermessungsämter in nrw.

Wieso sollte "die" denn Daten nach OSM importieren? das machen schließlich im Falle eines Falles "wir" und nicht die Ämter/Behörden.

Gruss
walter

toc-rox · 2013-10-27 11:30:46

openzzz wrote:

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.

Die Kaufversion (sogenannte "löhnware" ) zeigt die aktuellen Werte für DOP/HDOP/VDOP.

Gruß Klaus

PS: Um diesen Thread nicht zu kapern, sollten wir für das Thema einen Neuen eröffnen.

openzzz · 2013-10-27 12:41:28

toc-rox wrote:

Die Kaufversion (sogenannte "löhnware" ) zeigt die aktuellen Werte für DOP/HDOP/VDOP.

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).

Last edited by openzzz (2013-10-27 12:46:03)

Chenshi · 2013-10-27 12:45:54

wambacher wrote:

Wieso sollte "die" denn Daten nach OSM importieren? das machen schließlich im Falle eines Falles "wir" und nicht die Ämter/Behörden.
Gruss
walter

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

chris66 · 2013-10-27 16:40:04

seichter wrote:

die Hausnummern kommen dann woanders her und beim Übertragen kann es eben Fehler geben.

Gibt es einen zentralen Emailkontakt wo man ALK Fehler melden kann? Oder legt NRW da keinen Wert drauf?
Chris

Nakaner · 2013-10-27 18:36:10

openzzz wrote:

Früher in NMEA-Recordings hatte ich wenigstens noch die DOP-Werte drin, dass man wusste wie schlecht es ist. Heutzutage in den Smartphones gibt es meist nur noch GPX-Tracks ohne Integritäts- und Genauigkeitsdaten. Btw: gibt es eigentlich Apps die das können? Ich hatte bei Samsung den Verdacht, dass so etwas gar nicht mehr über die API geliefert wird, also die App auch bei gutem Willen kein NMEA inkl. DOP mehr ausgeben könnte.

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.

Nakaner · 2013-10-27 18:38:46

chris66 wrote:

seichter wrote:
die Hausnummern kommen dann woanders her und beim Übertragen kann es eben Fehler geben.
Gibt es einen zentralen Emailkontakt wo man ALK Fehler melden kann? Oder legt NRW da keinen Wert drauf?
Chris

Für die ALK sind die jeweiligen unteren Vermessungsbehörden zuständig. Das sind in NRW die Vermessungsämter der Kreise und kreisfreien Städte.

Was für Fehler willst du denn melden?

chris66 · 2013-10-27 18:52:17

Siehe oben, z.B. vertauschte Hausnummern.

Last edited by chris66 (2013-10-27 18:52:37)

Nakaner · 2013-10-27 19:02:08

chris66 wrote:

Siehe oben, z.B. vertauschte Hausnummern.

Schreib mal einfach das zuständige Vermessungsamt an.

chris66 · 2013-10-27 19:34:23

Done.

schiki · 2013-10-27 20:31:53

openzzz wrote:

Welche Touren vom Geoportal RLP meinst du denn? Ich konnte da keine finden. Auf einer Magic-Maps DVD (amtliche Topo25-Karten) hatte ich mal eine Sammlung von Touren drauf. Das waren nicht die offiziellen Wanderwege, sondern touristische Tourenvorschläge eines Verlages.

Hatte ich falsch in Erinnerung - war http://www.lvermgeo.rlp.de/index.php?id=5552 - diese Routen dürften so auch in den vom LVERM herausgegebenen Karten erscheinen.

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.

EvanE · 2013-10-27 20:56:26

Chenshi wrote:

kann mir eigentlich jemand die garantie geben, das die in nrw niemals nie die alk gebäude in osm importieren werden und man die wirklich manuel abzeichnen muss? ich hab keine lust wenn die jetzt schon soweit gehen das sie die alk zur verfügung stellen, man anfängt abzuzeichnen, und die in einem jahr doch noch ein schritt weiter gehen, und man gezielt daten (gebäudeumrisse) importieren kann. das wär sehr frustrierend.
gibts eigentlich ein tool in josm womit man automatisch einen umriss erkennen lassen kann und josm zeichnen dann automatisch das gebäude? dann müsste man nur noch selber die hausnummer einfügen und fertig.

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.

Edbert (EvanE)

seichter · 2013-10-27 22:03:37

openzzz wrote:

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).

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.

seichter · 2013-10-27 22:20:28

Chenshi wrote:

kann mir eigentlich jemand die garantie geben, das die in nrw niemals nie die alk gebäude in osm importieren werden und man die wirklich manuel abzeichnen muss? ich hab keine lust wenn die jetzt schon soweit gehen das sie die alk zur verfügung stellen, man anfängt abzuzeichnen, und die in einem jahr doch noch ein schritt weiter gehen, und man gezielt daten (gebäudeumrisse) importieren kann. das wär sehr frustrierend.
gibts eigentlich ein tool in josm womit man automatisch einen umriss erkennen lassen kann und josm zeichnen dann automatisch das gebäude? dann müsste man nur noch selber die hausnummer einfügen und fertig.

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.

EvanE · 2013-10-27 22:23:24

chris66 wrote:

EvanE wrote:
Die Wattendorfer Allee (Kottenforst Richtung Pecher Straße / L158) ist seit Jahren nicht mehr mit der L158 verbunden, sie endet einfach im Wald. In OSM ist das noch falsch, in der DGK5 ist das richtig eingetragen.
Dort ist es als Reitweg eingetragen der kurz nach der Wegkreuzung abbiegt. So hab ich's nun in OSM eingetragen.
Der folgende Weg sollte evntl. gelöscht werden (laut "note" wurde er renaturiert) :
http://www.openstreetmap.org/browse/way/66461915

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.

Gefühlt schon Mitternacht
Edbert (EvanE)

openzzz · 2013-10-28 00:14:13

EvanE wrote:

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.

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.

Last edited by openzzz (2013-10-28 00:15:49)

openzzz · 2013-10-28 00:29:18

schiki wrote:

Hatte ich falsch in Erinnerung - war http://www.lvermgeo.rlp.de/index.php?id=5552 - diese Routen dürften so auch in den vom LVERM herausgegebenen Karten erscheinen.
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.

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.

openzzz · 2013-10-28 01:18:11

seichter wrote:

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.

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.

EvanE · 2013-10-28 13:35:05

openzzz wrote:

EvanE wrote:
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.
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.

Wie so oft, sind das auf einer Wiki-Seite beschriebene Soll und die gelebte Mapper-Praxis zwei verschiedene Dinge. Es ist nun einmal viel einfacher nur ele=* zu schreiben, als sich über das Referenz-System Gedanken zu machen.

Berge sind in der Regel nur mit ele=* erfasst. Und ich wage zu bezweifeln dass von deren Werte überhaupt welche nach WGS84 erfasst sind. Eher stammen die von lokalen Infotafeln oder aus der Wikipedia (auch nach lokalem Referenz-System).

Allgemein bin ich der Meinung, dass man die Wikiseite Key:ele an die Mapping-Praxis anpassen sollte, also das mit ele=* eine Höhenangabe nach lokaler Info und Referenz-System verstanden wird. Die Forderung die Höhenangaben nach WGS84 umzurechnen, werden nur die wenigsten erfüllen können / wollen. Höhenangaben nach WGS84 sollten dann mit ele:WGS84=* kenntlich gemacht werden.

PS-1: Trägt jemand außer mir systematisch Höhen nach der NRW-Atlas DGK5 ein?
PS-2: Nutzt denn jemand in seinen 3D-Renderer Höhenangaben in OSM für das Terrain?
PS-3: Wie groß ist der Unterschied zwischen DHHN12 (alte Bundesländer), SNN76 (neue Bundesländer) und dem gemeinsamen DHHN92 nach 1992?

Edbert (EvanE)

streckenkundler · 2013-10-28 13:48:44

EvanE wrote:

PS-3: Wie groß ist der Unterschied zwischen DHHN12 (alte Bundesländer), SNN76 (neue Bundesländer) und dem gemeinsamen DHHN92 nach 1992?

Da lässt sich kein eindeutiger Wert festlegen. Vergleiche:http://de.wikipedia.org/wiki/Deutsches_ … %B6hennetz und hier den Abschnitt Vergleich der Systeme Deutschlands.

Bei den Höhenangaben ist die Angabe des Höhenbezugssystems zwingend erforderlich. Höhenangaben ohne Angabe des Bezussystems sind weitestgehend wertlos.

Ergänzung: siehe auch: http://www.bkg.bund.de/nn_175422/DE/Bun … __nnn=true

Sven

Last edited by streckenkundler (2013-10-28 13:56:42)

hurdygurdyman · 2013-10-28 13:53:20

streckenkundler wrote:

...
Bei den Höhenangaben ist die Angabe des Höhenbezugssystems zwingend erforderlich. Höhenangaben ohne Angabe des Bezussystems sind weitestgehend wertlos.
Sven

Ein Blick in die englische Wiki http://wiki.openstreetmap.org/wiki/Key:ele macht einiges klarer:
Elevation (height above sea level) of a point in metres. This is mainly intended for mountain peaks but could also be used for elevation of airport runways and many other objects. For OpenStreetMap, please use the elevation above sea level defined by the World Geodetic System, revision WGS 84.

edit: link

Last edited by hurdygurdyman (2013-10-28 13:54:12)

streckenkundler · 2013-10-28 14:06:46

hurdygurdyman wrote:

Ein Blick in die englische Wiki...

ja, ja, jetzt erinnere ich mich. Die ele-Disskussion hatten wir schon mal... Gut.
Vorausgesetzt, daß jeder Mapper, die WGS84-Höhe (über "sea level") auch verwendet, dann wäre die Angabe natürlich auch verwendbar. Ich befürchte jedoch, daß die Mapper-Realität anders aussieht: Mapper besteigt einen Berg findet eine Tafel mit dem Namen und der Höhe des Berges vor. Macht mit seinem GPS einen Wegepunkt. Mapper hat nun zwei Zahlen: die der Tafel (sicherlich keine WGS84- Höhe) und die des GPS (barometrische Höhenmessung und daher eh zu ungenau). Welche soll er verwenden?

Sven

seichter · 2013-10-28 14:10:59

openzzz wrote:

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.

Entscheidend für den Höhenfehler ist nicht der Radius der Kugelschalen (Fläche gleicher Entfernung), sondern der Winkel der Schalen an den Schnittflächen zueinander, sprich die Position der Satelliten zueinander. Stehen die Satelliten nahe beieinander, ist das Ergebnis in allen Dimensionen schlecht, stehen sie in einer Linie, ist das Ergebnis in Richtung dieser Linie gut, in der Fläche senkrecht dazu schlecht. Für die dritte Dimension braucht man keinen Satellit über Kopf, zwei auf 45 und -45 Grad reichen genauso. In hohen Breiten hat man zu selten (oder überhaupt nicht) Satelliten in der optimalen 90-Grad-Konstellation.
Natürlich kann es bei schlechten Bedingungen (Schluchten, Reflexionen etc) vorkommen, dass alle Logger Unfug ausrechnen. Mir ist es bei inzwischen Tausenden von Kilometern simultaner Tracks aber noch nie vorgekommen, dass diese Ausreisser bis auf wenige Meter übereinstimmten.

Announcement

#101 2013-10-27 10:53:00

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

#102 2013-10-27 11:11:20

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

#103 2013-10-27 11:29:35

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

#104 2013-10-27 11:30:46

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

#105 2013-10-27 12:41:28

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

#106 2013-10-27 12:45:54

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

#107 2013-10-27 16:40:04

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

#108 2013-10-27 18:36:10

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

#109 2013-10-27 18:38:46

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

#110 2013-10-27 18:52:17

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

#111 2013-10-27 19:02:08

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

#112 2013-10-27 19:34:23

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

#113 2013-10-27 20:31:53

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

#114 2013-10-27 20:56:26

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

#115 2013-10-27 22:03:37

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

#116 2013-10-27 22:20:28

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

#117 2013-10-27 22:23:24

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

#118 2013-10-28 00:14:13

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

#119 2013-10-28 00:29:18

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

#120 2013-10-28 01:18:11

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

#121 2013-10-28 13:35:05

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

#122 2013-10-28 13:48:44

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

#123 2013-10-28 13:53:20

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

#124 2013-10-28 14:06:46

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

#125 2013-10-28 14:10:59

Re: Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

Board footer