Done.
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.
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)
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.
Gefühlt schon Mitternacht
Edbert (EvanE)
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.
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)
Da lässt sich kein eindeutiger Wert festlegen. Vergleiche:http://de.wikipedia.org/wiki/Deutsches_Haupth%C3%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/Bundesamt/Geodaesie/RefSys/RefHoehe/Hoehe02__node.html__nnn=true
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
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
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.
Da magst du teilweise recht haben, dass die Mapper-Realität anders aussieht. Allerdings unterstelle ich jetzt einfach mal (,da ich an das gute im Menschen glaube), dass der gewissenhafte Mapper vor Verwendung eines key/value-Paares für ihm bis dahin nicht vertraute Sachverhalte vesucht, sich in der Wiki schlau zu machen und somit für ele=* die richtige Beschreibung findet und anwendet.
Hier bietet Wiki ja eben die Möglichkeit, “ele:xyz=123” anzugeben. wiobei xyz gleich einem Kartendatum ist (korrekter wäre es Höhenreferenz-System zu sagen). Ich schlage vor im Wiki eine Liste eine dieser Höhenreferenzsysteme mit einer kurzen Angabe zur Verwedung und Verbreitung zu erstellen.
Taginfo kennt nur 48 verschiedene ele:xyz-Werte (Stand 28.10.2013 14:25 Uhr) von denen einige auf unterschiedliche Schreibweisen beruhen.
Sven
Das finde ich aber sehr bedenklich, wenn “in der Praxis” falsche Angaben gemacht werden. Das wäre so, als würde man falsche Koordinaten eintragen, z.B. Easting-Northing statt Längen/Breitengrad. Wenn Daten automatisch verarbeitet werden geht das nicht. Wenn da keine Grad stehen kann man das noch erkennen, aber falsche Höhenangaben fallen auf der 2D-Karte eben nicht auf, obwohl die doch sehr verschieden sind, immerhin 47 Meter. In den Alpen sind das vielleicht Peanuts, aber im Flachland oder Vorgebirge ist das schon deutlich. Im Prinzip sind dann quasi alle Höhenangaben wertlos, wenn man nicht weiss nach welchem System gemappt wurde. Ich erinnere mich an ähnliche Diskrepanzen zwischen Gauß-Krüger Grad und WGS84 Grad. Das wäre auch eine Abweichung die schlimm ist (100m?), aber beim Blick auf den Zahlenwert noch nicht unmittelbar auffällt.
Man kann auch nicht für Deutschland Sonderregeln aufstellen. Das müsste für OSM weltweit einheitlich sein. Einheitlich geht nur mit WGS84. Es ist ja nicht schlimm, wenn jemand die DHHN92-Höhe einträgt, die auf amtlichen Topokarten bzw. im Alltag üblich ist. Aber das muss man wirklich kennzeichnen. Wer DHHN nicht aussprechen kann, der darf ruhig ele:local= schreiben. Bei der automatischen Verarbeitung wird das dann schon automatisch umgerechnet. Es fehlt wohl eher noch Aufklärungsarbeit, vielleicht ein Warn-Popup für JSOM-Anfänger. Oder dass JOSM und der Webeditor einfach gezielt nach dem System fragen. Dann würde der Mapper wenigstens sofort sehen, dass er eine falsche Angabe macht.
Wenn in der OSM-Datenbank so viele falsche Werte schlummern, müsste man das mal systematisch korrigieren. Wegwerfen wäre die radikale Methode. Oder man extrahiert alle Höhenwerte aus der Datenbank und vergleicht mit den STRM-Höhendaten. Dann könnte man automatisch erkennen lassen, ob der Wert näher am WGS84 oder am DHHN liegt. Da die STRM-Daten auch manchmal daneben liegen müsste man wohl nochmal prüfen ob das auch stimmt. Ich vermute es gibt noch nicht viele Höhen in OSM, weil man meist in 2D arbeitet. Außerdem vertraue ich meinem GPS-Gerät bei der Höhe sowieso nicht - aus Erfahrung.
Ich denke die Höhe auf der Tafel sollte korrekter sein und aus der Landvermessung (Triangulation) stammen.
Andererseits ist GPS auf der Bergspitze auch realtiv gut, weil da oben mehr Satelliten zu sehen sind.
Beachte diesen Satz aus dem Wiki
“The elevation in a local datum can be tagged as ele:local=*, with elevation specified in meters.”
Das ist doch einfach, oder?
Hier in Mitteleuropa weicht die Höhe der lokalen “Kartoffelschale” von WGS84 um etwa 40 m ab. So etwas ist unvermeidlich, da das Referenzellisoid von WGS84 weltweit gelten muss, also überall von einer lokal optimalen Näherung abweicht (sogar die Senkrechte hat einen Fehler). Manche GPS-Geräte korrigieren diese Abweichung automatisch, bei manchen lässt es sich einstellen, bei anderen weiß man es nicht.
Die Angabe im Wiki finde ich für die Höhe etwas an der Praxis vorbei. Was in der Ebene sehr sinnvoll ist (nur ein Längen-/Breitensystem weltweit), ist in der Höhe nicht so praktikabel. Es wird mit Sicherheit noch sehr lange dauern, bis an allen Aussichtspunkten die lokale und die WGS84-Höhe aufgeführt werden. Ob sich die Deichanlieger damit anfreunden können, dass der Meeresspiegel z.B. zwischen -30 und -25 m bei Ebbe und Flut wechselt, scheint mir auch zweifelhaft. Das ist zwar für eine weltweites System unbefriedigend, da ein Grenzgipfel da zwei Höhen haben kann, aber sonst sind entweder Adria oder Nordsee (oder beide) nicht auf Höhe 0. Mit Länge und Breite hat man dieses Nullproblem nicht, außer man steht gerade in Greenwich auf dem in den Boden eingelassenen Nullmeridian.
Mit Einträgen von ele:xy=* hätte ich keine Problem.
Barometrische Höhenmessung ist übrigens so schlecht nicht, wenn zu Beginn mit einer bekannten Höhe kalibriert und der meteorologische Luftdruck (Sturmtief) sich nicht zu schnell verändert. Das läuft auf eine Differenzmessung hinaus und über WGS84-Höhen braucht man sich nicht den Kopf zu zerbrechen.
Das wäre genau so falsch. ele:local=… sagt nur noch aus, daß es eine lokale Höhenangabe ist, aber nicht nach welchem System. Da müsstest du mit local=… den lokalen Bezugspunkt mit angeben. Angaben mit ele:local=… sollten weitesgehend vermieden werden, da die ohne Angabe des lokalen Bezugspunktes wertlos.
Taginfo (28.10.2013, 14:45Uhr):
ele:local=1348 mal
local=… 15 mal
Das sind 1333 nicht definierbare lokale Höhenangaben.
Wenn, dann ele:DHHN92=… oder ele:NHN=… ich würde ersteres bevorzugen.
+1
Sven