Nutzung des NRW-Atlas für OpenStreetMap-Zwecke

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?

Wir haben jetzt gleichzeitig zwei Threads zum selben Thema hier im Forum. Wie maxbe heute morgen möchte ich euch bitten, doch in folgendem Thread weiter zu diskutieren und euch dort einzubringen: http://forum.openstreetmap.org/viewtopic.php?id=21009&p=2

Und mappen die auch schön alle international in km/h. Oder die Amis vielleich doch in miles-per-hour?

Wäre es nicht mega-schlampig, wenn man das nicht per Definition klarstellt, bevor man munter drauflos-mappt?
Ich finde das Beispiel eigentlich ganz gut, warum Definitionen wichtig sind.
*)

Amis haben da oft eine andere Einstellung. In NMEA ist die speed beispielsweise als Knoten definiert.
Das muss immer umgerechnet werden. Und ich bin heilfroh, dass nicht irgendwelche Deutschen Spinner
da auf einmal die Definition brechen und km/h im seriellen Protokoll übermitteln.

In Google-KML-Code habe ich schon Sourcecode-comments wie “these European communist bastards”
gelesen, weil einer mit der km/h Definition nicht einverstanden war.
Da muss man einfach drüberstehen. Definition ist Definition.

Bei der NASA gab es Spassvögel, die das missachtet haben.
… und veranwortlich für mindestens einen Raketenabsturz sind

Zum Glück wird OSM nicht Grundlage für Flugzeugkarten, sonst würden sie wohl
beim Landeanflug Crashen. Da sind 40 m Unterschied relativ viel.

Aber ich finde es nicht fair, dass entweder die Iren oder die Deutschen ihre Berg-Höhenangaben
ändern müssen, nur weil manche oder alle sich nicht an Definitionen halten.

*) p.s. die einheitliche Definition ist für OsmAnd wichtig, weil es bei Geschwindigkeitsübertretungen warnen kann.
Wäre ziemlich nervig wenn es dauernd falschen Alarm gibt, nur weil die Einheiten nicht stimmen.

Und was hat das nun schon wieder mit dem NRW-Atlas zu tun?
Kopfschüttelnd, Chris

Nichts. Aber die Einsicht sollte bei allen reifen, dass wir ein sauberes Datenmodell brauchen.
Mit dem NRW-Atlas kommen wieder neue Koordinatensysteme. In Gauß-Krüger hat man
leicht mal einen Horizontalversatz von 100m, wenn man mit der Umrechnung nicht korrekt umgeht.
Und bevor jemand aus dem NRW-Altas die Höhen abpinnt sollte er sich auch über das Höhenmodell klar sein.

Nochmal als Moderatorhinweis:

Bitte alle Diskussionen zu Höhenangaben und deren Codierung im dafür vorgesehenen Thread weiterführen:
http://forum.openstreetmap.org/viewtopic.php?id=21009

Hier bitte nur noch sachdienliches zum NRW-Atlas.

bye, Nop

Um noch einmal auf die ursprüngliche Freigabe zurückzukommen:

Ich frage mich, wie in diesem Zusammenhang das “automatische Abmalen” per Tracer2-Plugin zu sehen ist. Für mich sieht dies eher nach einem “Kopieren von Datenbankinhalten” aus: die per WMS erhaltenen Daten werden in ein anderes Format überführt und gespeichert, die Inhalte bleiben dieselben im wesentlichen unverändert. Oder wird es noch als “Ableitung von Geodaten” angesehen, weil ja nicht der gesamte Inhalt des WMS-Layers automatisch gespeichert wird?

Ich bin ehrlich gesagt immer noch irritiert über die großherzige Freigabe, die in so diametralem Kontrast zur vorherigen jahrelangen Totalverweigerung steht.
Insbesondere weil die “Ableitung von Geodaten” (d.h. nach unserem Verständnis das Abzeichnen von Objekten, nun ggf. sogar automatisiert) ganz lapidar nach “Lagekontrolle, Qualitätssicherung” erwähnt wird, frage ich mich, ob der Ansprechpartner bei der Bezirksregierung Köln damit vielleicht mehr erlaubt hat, als ihm bewußt war, bzw. keine Vorstellung davon hatte, wie wir die Formulierung auslegen (und nutzen). Faktisch können wir mit den neuen Mitteln des Tracer2-Plugins die komplette ALK (mit für unsere Zwecke verkraftbaren Verlusten bei der Genauigkeit) duplizieren. Das halte ich schon aus OSM-Sicht nicht für wünschenswert; aber ich kann mir auch nur schwer vorstellen, daß es seitens der Landesregierung so gewollt war.

Ich hab da auch ein sehr, sehr ungutes Gefühl.

Gruss
walter

Mir ist auch etwas unwohl bei dem automatisierten und gedankenlosen Umgang mit dem Tool. Die Auswirkungen werden wohl nicht so schlimm werden wie in Frankreich.

Ich vermute, dass die Bezirksregierung Köln nicht so ganz glücklich über die Entwickung sein dürfte und dies auch Auswirkungen auf die Bemühungen zur Datenfreigabe von WMS-Diensten (außer Luftbildern) in anderen Bundesländern haben dürften, da der schwammige Begiff “abmalen” jetzt eigentlich durch “kopieren” zu ersetzen wäre.

Persönlich halte ich den Informationsgehalt reiner Hausumringe für OSM-Zwecke eher für gering, solange sie nicht durch die Adresse nach dem Karlsruher Schema veredelt sind. Hierzu ist noch immer einiges an Handarbeit erforderlich verknüpft mit einer Kontrolle vor Ort bei Unklarheiten oder Zweifeln.

Auch bei Maps4BW gab es schon Probleme, weil “Quantitäts-Mapper” in Wirklichkeit nicht existierende Waldwege großflächig nachgezeichnet haben.

OSM profitierte in Deutschland bisher vorallem von der aktuellen Ortskenntnis seiner Mapper und dem daraus resultierenden Datenbestand. Es war zwar nicht alles in der Karte, aber was drin war, darauf konnte man sich verlassen. Wir sollten uns allmählich Gedanken machen, wie wir einen schleichendem Qualitätsverlust entgegenwirken.

Grüße
Joachim

Könntest Du da vielleicht noch einmal nachhaken? Wenn man bloß “nicht ganz so glücklich” wäre, aber keinen Verstoß gegen die Nutzungsbedingungen sähe, wäre es ja halb so schlimm: Bei allzu großer Betrübnis könnte die Behörde die Nutzungsbedingungen ändern und ab dem Zeitpunkt des Inkrafttretens dürfte nicht mehr abgezeichnet werden.
Mehr Sorgen macht mir (abgesehen von den qualitativen Auswirkungen auf OSM, wo ich Deine Bedenken teile) aber die oben angedeutete Möglichkeit, daß das (automatisierte) Abzeichnen schon jetzt gegen die Nutzungsbedingungen verstößt. Es wäre unschön, wenn nach einigen Monaten hunderttausende hereingeklickte Gebäude gelöscht werden müßten, weil sich herausstellt, daß deren Übernahme unzulässig war. Das geschähe dann sowieso wieder nur halbherzig bzw. scheitert auch daran, daß die entsprechenden Beiträge nur teilweise identifziert werden können, und wir hätten jede Menge illegitime Daten in der Datenbank.

Stimmt, das sollte möglichst schnell geklärt werden. :slight_smile: