Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

Die Unterschiede der Geoide kann man für OSM mMn getrost vernachlässigen.
Natürlich muss für den Auswerter eindeutig definiert werden, was ein ele=* bedeutet. Im Moment stehen sich nur die Aussage im Wiki und die Mapping-Praxis zu 99% (oder mehr) diametral gegenüber.
Eine ketzerische Frage: Was lässt sich leichter ändern?

Nahmd,

Das ist eine bösartige Beleidigung der Tausende Mitstreiter, die seit Jahren Daten zusammentragen, und all der Verwalter der Karten und Tools, die bereits im täglichen Einsatz sind. Besser Daten, die hinreichend gut sind und existieren, als perfekte Daten, die nicht existieren.

Der Unterschied zwischen Theorie und Praxis ist in der Praxis größer als in der Theorie.

Definiert wird es durch das, was die Datenerfasser eintragen. Und wenn fast alle lokale Höhenangaben eintragen, dann stehen fast nur lokale Höhenangaben in der Datenbank. So einfach ist das. Und das Wiki muss angepasst werden. Dookratie at its best. Raus mit dem weltfremden WGS84-Quatsch aus dem Wiki und stattdessen “ortsübliche Höhenangaben”. Das “ortsüblich” genauer zu definieren, bringt nix: der Hüttenwirt kann mir nicht sagen, auf welches System sich die Höhenangabe auf der 90 Jahre alten Holztafel bezieht. Und zwischen den Höhenangaben auf meinen über 100 Jahren alten Karten und den heutigen liegen vielleicht mal 10 Meter, ein Wert, der in der Praxis nicht interessiert. Und – ich formuliere mal flapsig – ob man sich auf Nordsee, Ostsee, oder Adria bezieht, macht schlimmstenfalls mal nen Meter aus. Who cares?

Nicht falsch verstehen: natürlich ist das alles sehr schwammig jetzt, und es spricht nichts dagegen, das ganze auf eine saubere Grundlage zu stellen. Aber bitte: mit einem neuen Tag. “ele_wgs84” oder was auch immer. Egal wie ihr das “ele=*” definieren wollt: da werden weiterhin täglich die vor Ort vorgefundenen Daten eingetragen. Und das ist auch gut so, denn nur deshalb haben bereits jetzt unsere Berge und Pässe Höhenangaben.

Die Vorstellung, dass ein paar Heinzl aus dem deutschen Forum da irgendetwas vorschreiben und die zigtausendfach bewährte Methode der Erfassung “irgendwie definierter Höhen” verbieten könnten, ist absurd.

Die korrekte Vorgehensweise wäre: definiert einen neuen Schlüssel “ele_wgs84”. Dann setzt dieses Tag für möglichst viele OSM-Objekte. Wie ihr an die Daten kommt? Keine Ahnung. Und wenn (größenordnungsmäßig) ähnlich viele Objekte mit “ele_wgs84” getaggt sind wie mit “ele”, und wenn ihr die Übersetzungsproblematik geklärt habt, und wenn ihr die implementierten Algorithmen und die zugehörigen Parameter dern Datennutzern bereitstellen könnt, dann, ja dann kann man beginnen, eine Umstellung zu diskutieren.

Visionen alleine sind zu wenig.

Gruß Wolf

Und schon sind wir wieder bei einem Unterschied.
Die Waldwege für Maps4BW stammen nach meiner Erinnerung von der Forstverwaltung, die ein Interesse hat, ihre alten Rückewege auch in Zukunft benutzen zu können und gleichzeitig wenig Interesse hat, die Waldwege ständig zu aktualisieren.
Beim NRW-Atlas stammen die Daten zu den Waldwegen meines Wissens nach von der Geoverwaltung und sind zumindest in meinem Gebiet recht aktuell.

Die Problematik “Wie aktuell sind die Daten?” und “Wie sind Gebäude eingetragen?” besteht natürlich überall. Schließlich gibt es bei jedem Kartenwerk einen Stichtag, nach dem keine Änderungen mehr einfließen. Aber die Gebäude-Erfassung scheint je Land einheitlich zu sein, bzw. es gibt einen Wechsel Dach → Mauerwerk oder eben nicht.

Also nichts gegen eine Übersichtsseite mit allgemeiner Erwähnung möglicher Probleme. Aber die Ausprägung sind je Land unterschiedlich und daher sollte Problem bei den Ländern besprochen werden, wo sie wirklich auftreten.

Die Probleme sind sicher überall gleich, wenn auch die Ausmaße unterschiedlich sind. Bei Maps4BW haben wir anscheinend nur die üblichen Höhenangaben für Berge, beim NRW-Atlas, genauer deren DGK5 haben wir sehr viel mehr Höhenangaben.

Ich bin übrigens dagegen Problembeschreibungen auszulagern, dann werden sie noch weniger beachtet, als sowieso schon. Auf einer Übersichtsseite für alle Bundesländer kann / soll man die Probleme durchaus ansprechen, aber dort wo sie verstärkt auftreten, sollte man sie gezielt zum Thema machen.

Durch Redundanz, findet man die Problembeschreibung dort, wo sie tatsächlich existieren und nicht in eiorgendeinem verlinkten Dokument, das man dann auch noch grne übersieht, weil einem das Stichwort nichts sagt.
Keine / wenig Redundanz ist kein Wert an sich, sondern für strukturierte Datenbanken eine Arbeitserleichterung. Die Benutzung der Daten wird durch die Notwendigkeit, sich all die vielen Redundaanz-Schnippsel zusammen suchen zu müssen, hingegen sehr viel aufwändiger.

20 Jahre nach der Umstellung solten alle aktuellen Kartenwerke auf dem ‘neuen’ System beruhen.
In den alten Bundesländern ist der Unterschied zwischen DHHN92 und DHHN12 zudem so gering, dass bei den Höhenangaben mit 0.1m Genauigkeit dies nur sehr selten zum tragen käme. Und selbst wenn, die paar Ausreißer (mit +/- 0.1m) tun uns bei der neuen Datenfülle überhaupt nicht weh.

Bitte teil uns doch mit, welche Bundesländer wann auf DHHN92 umgestellt haben und welche ggfs. noch nicht. Ohne diese Information ist deine obige Aussage nur FUD (bitte im EDV-Lexikon nachschlagen).

Edbert (EvanE)

Hallo Wolf

Danke, du hast meinen Abend gerettet.
PS: Hervorhebung von mir.

Und jetzt will ich endlich Mappen!
Edbert (EvanE)

Für Karten ist die Definition des Koordinatensystems so ziemlich das Elementarste überhaupt.
Da kann man nicht schlampen. Wie gesagt, die Karte sähe ziemlich schrottig aus, wenn man in
Frankreich die “ortsüblichen” Lambert-Koordinaten benutzen würde.
So weltfremd finde ich WGS84 gar nicht. Das ist die Basis der meisten GEO-Anwendungen.
Das spucken die GPS-Geräte aus (NMEA-Felder), Google KML nutzt es. UTM-Karten nicht,
aber wer trägt schon Easting-Norting statt Longitude/Latitude in OSM ein?
UTM wird regulär in WGS84 umgerechnet.

Derzeit sind ele-Tags als WGS84, ele:local als lokale NHN definiert. Wer’s genau nimmt
kann mit ele:xyz das System konkret angeben. Wo ist das Problem? Ist doch sauber definiert.

Wenn du mit der OSM-Regelung nicht einverstanden bist müsstest du das auf Gesamtprojektebene
ansprechen. Das muss für OSM einheitlich sein.

Es wäre den App-Programmierern, z.B. von OsmAnd, nicht zuzumuten die ganzen regionalen
Vorlieben zu berücksichtigen. Oder für den Renderer, der die Berghöhen einzeichnet.
Wer Geodaten verarbeitet, muss sich auf eine klar definierte Datengrundlage verlassen können.

Die 92 steht dafür, dass die letzten Nivellements (Höhenmessungen) in den Jahren 1990-92 durchgeführt worden sind. Der Beschluss zur Einführung wurde 1993 gefasst. 1994 fand die Ausgleichung statt. Siehe auch http://www.pfiff.nrw.de/hilfe/dok/pi_normalhoehen.pdf Die meisten Ländern haben DHHN92 erst in den 2000er-Jahren für ihr Höhenfestpunktfeld eingeführt.

Laut meiner Google-Recherche sind die Höhenfestpunktfelder in folgenden Ländern umgestellt: Thüringen, Bayern, Baden-Württemberg, Saarland, NRW, Schleswig-Holstein, Mecklenburg-Vorpommern, Sachsen-Anhalt, Brandenburg, Berlin, Sachsen. Bei den anderen habe ich auf die Schnelle nichts zur Umstellung gefunden.

Und wie gesagt - die eigenmächtige und undiskutierte Änderung eines einzelnen Mappers damals ist in meinen Augen keine Definition. Ganz besonders wenn sie in der Praxis fast komplett ignoriert wurde.

bye, Nop

Also du meinst das hier definiert nicht den ele-Tag?

http://wiki.openstreetmap.org/wiki/Key:ele

Und was sonst? Ist der undefiniert? Macht jeder was er will?
Dann sollte das mal zentral für OSM abgestimmt werden.

Ich meine daß auf dieser Seite ein einzelner Mapper ohne vorherige Diskussion oder Unterstützung von mehr als seiner eigenen Meinung die bestehende Definition “m über NN” auf eine Aussage geändert hat, die völlig an der Realität vorbei geht. Und damit Chaos und Unsicherheit erzeugt hat.

Um es als Definition zu akzeptieren müßte es für mich entweder

  • die bis dato bestehende Definition kompatibel ergänzen anstatt sie zu invalidieren und
  • die reale Mappingpraxis wiedergeben
  • oder durch eine Diskussion und zumindest den Hauch einer Mehrheitsentscheidung mit mehr als einer Einzelmeinung belegt sein

Den jetzigen Zustand bezeichne ich als groben Fehler, nicht als Definition.

Und ja, leider ist es so daß bei OSM jeder macht was er grad lustig ist - und es kommt leider des öfteren vor, daß ein Einzelner völligen Blödsinn ins Wiki einträgt. Normalerweise wird das gleich wieder rückgängig gemacht. Aber wenn niemand aufgepaßt hat und das gleich wieder rausschmeißt, sieht es dann Jahre später so aus als wäre das “Gesetz”.

In diesem Fall hat einfach niemand hingeschaut. Wozu auch, jedem unbedarften oder pragmatischen Mapper ist intuitiv klar daß man das mappt was in der Realität zu sehen ist. Und das ist auf Schildern in Deutschland m über NN.

bye, Nop

Da ich mich nur ungern wiederhole :roll_eyes:
Und wie das unsere irischen Freunde 2009 bei einem Import gelöst haben, könnt ihr hier am Croagh Patrick sehen. Da die dem Wiki-Braten wohl auch nicht trauten, haben sie ele=* und ele:wgs84 =* sowie einige andere ele mit drauf gepackt, und so kann sich jede Auswertung nach Belieben bedienen.

Doch nun noch ein Vorschlag für die Zweifler an der richtigen Verwendung der wgs84-Höhe als Standard elends-value:
Statt hier weiter im Kreis und (zumindest teilweise OT) zu diskutieren, könnte doch mal jeder per overpass oder sonstwie die ele seiner Gegend suchen, kontrollieren und berichtigen. Da ich in dieser Diskussion einen Trend hin zu wgs84 als Standardhöhe sehe, was ja der wie auch immer zustande gekommenen Jahre alten Wiki-Definition entspräche, kann ja jeder die gefundenen ele entsprechend kennzeichnen:
ele:unknown=* >>(Höhensystem der Angabe unbekannt)
ele=* >>(wgs84-Höhe verifiziert
ele:= >>(whatever you want)

Wir könnten die Höhendiskussion auch hier fortsetzen: http://forum.openstreetmap.org/viewtopic.php?id=21009 http://forum.openstreetmap.org/viewtopic.php?id=18946 http://forum.openstreetmap.org/viewtopic.php?id=17034

Ich schlage vor, wir berücksichtigen alle drei Bestandteile des WGS84, ignorieren auch nicht das Kapitel 6 der Definition (PDF 1MB) (mehr amtliche Definition geht nicht…), und tragen die Höhe über dem Geoid ein. Wer das Wiki ändert, sollte auch gleich das erste Beispiel (Breithorn) ändern. Die dort angegebene Höhe ist eine über Meer.

Grüße, Max

Den Trend sehe ich so nicht … vielmehr sollte zusammen mit der Höhe in einem zusätzlichen Tag das Bezugssystem erfaßt werden. Desweiteren schließe ich mich maxbe an und schlage die Verlagerung der Diskussion in den genannten Thread vor.

Gruß Klaus

+1

Edit: wegen off topic gelöscht.

+1

Und die Berge hast du auch alle bestiegen und die Schilder abgelesen?
Oder Couch-Surfing und von der Wikipedia abgepinselt?

Nein, ich will da kein System zerschlagen, nur bevor ich irgendwelche Daten erfasse informiere ich wie die Felder definiert sind. Das sollte eigentlich jeder Mapper bevor er loslegt. Ich hatte für meine eigenen Projekte auch schon viele Datenstrukturen definiert. Da ist dann Selbstdisziplin erforderlich, auch wenn man später nicht immer glücklich mit seinen Entscheidungen ist. Ich habe auch schon Definitionen geändert. Das bedeutet dann aber, dass der komplette Datenbestand konvertiert werden muss, Programme umgeschrieben werden müssen etc. Darum macht man das ungern und eher selten. Am elegantesten ist es, von vorneherein sich gründlich Gedanken zu machen, um nachher nichts mehr umdefinieren zu müssen. Aber so wie hier, dass man jahrelang gegen eigene Regel verstößt hatte ich noch nie erlebt. Hast du noch nicht in großen Industrieprojekten gearbeitet, wo das ganze direkte monetäre Konsequenzen hat?

Ob das nun ein 3-er Satz an Koordinaten ist oder die Höhe separat ausgezeichnet wird, spielt doch keine Rolle ob man sauber definiert oder nicht. Sicherlich ist OSM ein zweidimensionales Modell und die Höhe nicht so sehr relevant.

Also ich verstehe, du willst die Bedeutung des ele-Tags umdefinieren (WGS84 → NHN / ü. NN). Wir können das gerne für OSM ganzheitlich durchsetzen. Aber da müssen wir wirklich erstmal an die Defintion ran, dass man sich auf eine internationale gemeinsame Grundlage stellt. Deutsche Sonderwege sind doch sinnlos.

Meine Frage zum Unterschied WGS84-Geoid-Höhe und DHHN92-Höhe ist noch nicht beantwortet worden. Ich finde die Meinung von Experten auch wichtig, also Geodäten die sich mit den Höhensystemen auskennen. Womöglich ist der Unterschied zwischen der WGS84-eigenen Geoidhöhe und den nationalen Systemen gar nicht so groß, so dass eine Definition ele = WGS84-Geoidhöhe relativ konsistent zum Datenbestand wäre. Dann müsste man nur dazuschreiben, dass die Geoid-Höhe gemeint war. NMEA gibt ja auch in erster Linie im Höhenfeld die Geoidhöhe an und liefert den Korrekturwert gleich mit.

Außerdem, wieso “elevation”? Ich kenne es in Geodaten nur als “altitude”. Elevation ist für mich ein Höhenwinkel.
Ich hatte schon gelesen, dass man das evtl. umdefinieren wollte, mit einem alt-Tag.
Eigentlich eine gute Gelegenheit dazu. Ich werds mal auf der OSM-Liste ansprechen.

Es wäre schlimm, wenn andere dann nach den OSM-Wiki-Leitlinien in WGS84 erfasst hätten
und wir einen ununterscheidbaren Mischmasch verschiedener Systeme hätten
(so wie 50% ü. N.N und 50% WGS-Höhe). Dann müsste man jeden Eintrag einzeln überprüfen,
wenn die Karten noch stimmen sollen.

Wenn aber sagen wir 99% der Einträge der Definition widersprechen ist die Lage hoffnungsvoller.
Dann könnte man entweder die Definition ändern oder alle bisherigen Einträger per
Datenbankscript auf ele:local umschreiben. Je nachdem wie man sich entscheidet.
Aber eine Entscheidung sollte her, bevor wirklich dieser Mischmasch entsteht.
Ich nehme normalerweise meine Definitionen zur Datenstruktur sehr ernst.

Ich bin der Meinung, dass wer Höhen nach WGS84 eintragen will, dies ausschließlich in ein Tagg ele:WGS84 (von mir aus auch ele:wgs84) tun sollte. Nur dann ist klar was real gemeint ist.

Ansonsten sollten wir die Diskussion wirklich im eigenen Thread weiterführen, wie es maxbe im Post #183 vorgeschlagen hat.

Edbert (EvanE)

Edit: wg. off topic gelöscht.

So einen lässigen Umgang mit Tags kannst du machen, wenn die nicht automatisiert verarbeitet werden.

Bei den Höhen ist es so, dass die auf der Karte angezeigt werden.
Da ist einfach eine klare Definition wichtig. Wenn ich die N.N.-Höhen darstellen will muss ich genau wissen in welchem Tag die wie formatiert drinstehen.

Wer das vernachlässt hinterlässt einfach einen großen Datenmüll.

Das kannst du jetzt schon beobachten: in Irland wird im ele= Tag die ellipsoide Höhe eingetragen. Der Renderer kann damit dann nicht anders umgehen als in Deutschland und schreibt die einfach auf den Berg. Irische Bergspitzen sind also WGS84-ell. ind er Karte und deutsche mehrheitlich als N.N.

Ist das nicht Murks? Soll der Renderer jetzt entscheiden, ach der Berg liegt in Deutschland und die Mapper dort haben ein anderes Verständnis als in Irland, also rechne ich nur fallweise um? Ich finde es einfach nur schlampig, wenn man nicht in der Lage ist, dafür klare Regeln aufzustellen und sich daran zu halten.

Der Schaden ist schon da. Entweder die Iren oder die Deutschen müssten die Daten umrechen, um konsistent zu bleiben. Ich will nicht sagen wer jetzt Recht hat, der Stärkere (wir Deutschen sind sowieso größer und stärker)? Solche Schäden werden mit deiner Einstellung verursacht, nach der man keine Regeln braucht oder das Regelbrechen Spaß macht. Sicherlich ist es erstmal mühsam, Datenstrukturen zu definieren. Aber sicherlich auch weniger Arbeit wenn man es anfangs gründlich macht und später nicht mehr ändern muss.

Wenn du unbedingt in N.N. mappen willst, kannst du das nicht international in der OSM-Community abstimmen, um Regeln entsprechend anzupassen?