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

EvanE wrote:

Nakaner wrote:

Die letzte Frage, worauf man achten sollte, braucht man IMHO nicht auf der Infoseite zu NRW beantworten. Da wir über kurz oder lang noch mehr Open-Data-Länder haben werden, sollte man im Wiki eine separate Seite mit "Hinweise zum Umgang mit deutschen Katasterdaten" anlegen. Diese könnte man dann von den einzelnen Länderseiten (MAPS4BW, NRW, Berlin, Hamburg) verlinken.

Je nach Bundesland sind die Ausprägungen gegebenenfalls sehr unterschiedlich.
Zum Beipiel besteht Maps4BW aus genau einer Karte, während der NRW-Atlas aus einer Ansammlung vieler Karten mit unterschiedlichen Ausprägungen besteht.

Einige Unterschiede seien exemplarisch genannt:
- Maps4BW hat eine schlechtere Auflösung als die ALK vom NRW-Archiv
- Maps4BW stellt etliche topographische Merkmale wie Böschungen
überhaupt nicht dar, die in der DGK5 des NRW-Atlas enthalten sind.
- Es ist natürlich einfacher wie bei Maps4BW nur eine Karte als
Hintergrund zu benutzen, statt sch aus dem NRW-Atlas die passenden
Karten/Layer zusammen suchen zu müssen.

Als Fazit gibt es vieles, was beim NRW-Atlas zu beachten ist (z.B. Höhenangaben), das bei Maps4BW jedoch überhaupt nicht auftaucht. Eine einheitliche Beschreibung ist zwischen den beiden nicht möglich.

Ich habe eigentlich eher an folgende allgemeinere Hinweise gedacht:

• Gebäudebestand im Kataster und den daraus abgeleiteten Produkten (DGK5, Maps4BW) ist nicht top-aktuell.
• Bei Gebäuden ist im Kataster in Westdeutschland und in Ostdeutschland bei Gebäuden, die nach der Wende entstanden sind, das "aufsteigende Mauerwerk" eingetragen und nicht der Dachvorsprung.
• Im Wald sind die amtlichen Daten nicht besonders aktuell.
• usw.

Die Höhenproblematik haben wir derzeit nur in NRW. Wenn aber noch weitere Ländern dem Vorbild NRW folgen, brauchen wir die Infos zu Höhen(bezugssystemen) nicht redundant ablegen.

openzzz wrote:

Man könnte natürlich auch grundsätzlich die lokale Höhe als Default für das ele-Tag definieren.

Bedenke bitte, dass es Länder gibt, in denen es mehr als ein Höhenbezugssystem gibt. Wir haben in der Deutschland derzeit drei:

• DHHN12 (Deutsches Haupthöhennetz 1912), auch unter der Bezeichnung Normal-Null (NN) bekannt, Bezugspegel Amsterdam, wurde/wird in den alten Bundesländern verwendet
• SNN76 (Staatliches Nivellementnetz 1976), auch unter der Bezeichnung Höhen-Null (HN) bekannt, Bezugspegel Kronstadt/Ostsee, wurde/wird in den neuen Bundesländern verwendet
• DHHN92 löst die beiden ab. Manche Länder (z.B. Sachsen-Anhalt und Baden-Württemberg) haben schon umgestellt, Bezugspegel Amsterdam

Auch wenn die Vermessungsverwaltung schon umgestellt hat, kursieren die Angaben in den alten Systemen noch recht lange. Schließlich lösen sich all die Kartenblätter und Höhentafeln an Wanderwegen nicht mit der Umstellung in Luft auf. Daher ist eine Definition des ele-Tags als Höhe im ortsüblichen System ähnlich unbrauchbar wie eine Angabe ohne Bezugssytem.

openzzz wrote:

Aber in der Datenverarbeitung wäre es besser mit einer weltweit einheitlichen Definition, vor allem wegen der Interoperabilität. WGS84 ist dafür schon eine gute Lösung. Vor allem wird es von den GPS-Geräten ausgespuckt. Die meiste Consumer-GEO-Software ist heutzutage WGS84-basiert. Die lokale Höhe sollte eher an der Benutzerschnittstelle berechnet werden, bei Eingabe oder Ausgabe. Beispielsweise könnte OSM bei eine ü.NN-Höhenangabe automatisch das WGS84-Datenfeld dazu anlegen.

Dazu mal die Frage in den Raum gestellt: Gibt es eine Tabelle mit den Geoidundulationen (d.h. Abstand WGS84-Ellipsoid zu DHHN12/DHHN92/SN76) unter einer freien Lizenz? Welche Maschenweite/Gitterweite und welche Genauigkeit hat diese? Die Vermessungsverwaltungen bieten solche Tabellen zum Kauf an.

Man sollte daher in den Editoren für die Höhenangebe eine Vorlage einbauen, bei der man eingeben kann, welches Bezugssystem die Höhe hat. Gibt der Benutzer WGS84 als Bezugssytem an, wird seine Höhe im ele-Tag gespeichert. Gibt er DHHN92 ein, landet die Höhe in ele:DHHN92. Gibt er gar nichts oder "unbekannt" ein, landet die Höhe in ele:unknown und jeder Datennutzer kann diese Angaben einfach herausfiltern. Die Editoren sollten dann aber auch einen Link zu einer allgemeinverständlichen Erläuterung des Höhenproblems (Unterschied ellipsoidischer Höhe–Gebrauchshöhe) bieten oder ele-Tags nicht in die OSM-DB hochladen. 🙂

Die Datennutzungssoftware (oder die Importtools für die Datenbaken, z.B. osm2pgsql), sollten fähig sein, ellipsoidische Höhen anhand einer Lookup-Tabelle in Gebrauchshöhen umzuwandeln. Auf osm.org sollte man IMHO die Anzeige von Höheninformationen abschalten oder immer als "435 (WGS84)" ausgeben, damit weniger Leute für den Renderer taggen.