Hochauflösende Höhendaten (1m !) für Nordrhein-Westfalen

Moderator: Roland Ziegler

Nachricht
Autor
Alwin Meschede
Beiträge: 7339
Registriert: 04.11.2001 19:57:46
Aktuelle Projekte: Zusi3 Objektbau
Kontaktdaten:

Re: Hochauflösende Höhendaten (1m !) für Nordrhein-Westfalen

#41 Beitrag von Alwin Meschede »

Ronny hat geschrieben:Dass Netz seine Daten nicht an Hinz und Kunz herausgibt, ist nicht unbedingt verwunderlich – genau wie bei jedem anderen Betrieb.
Nicht nur Hinz und Kunz bekommen keine Daten, selbst große A-Kunden lässt man verhungern. Ich hatte letztes Jahr die Gelegenheit, mit einem Softwareentwickler aus dem Haus DB Cargo zu sprechen, der dort das PVG-System betreut (mit dieser Software wird bei Cargo der Einzelwagenverkehr gesteuert). Seine Aussage war: Auch DB Cargo weiß nicht, welche Strecke in Deutschland wie geneigt ist. Wenn sie es wüssten, würde sie das sehr voranbringen. Sie haben auch keinen deutschlandweiten Datensatz darüber, welche Strecke welcher Streckenklasse zugeordnet ist. Für ein Güterverkehrs-EVU ist es schon relativ entscheidend, über die Streckenklasse Bescheid zu wissen, wenn man seine Güterwagen nicht überladen will. Natürlich kann man sich von Hand durchs Infrastrukturregister klicken, wenn man die Streckenklasse wissen will. DB Cargo würde das ganze aber gerne als gesamthaften Datensatz vom Netz haben. DB Netz hat sinngemäß geantwortet "da könnte ja jeder kommen..."
Mein Youtube-Kanal: youtube.com/echoray1

Benutzeravatar
Roland Ziegler
Beiträge: 5481
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

Re: Hochauflösende Höhendaten (1m !) für Nordrhein-Westfalen

#42 Beitrag von Roland Ziegler »

Nochmal zum generellen Umgang mit den 1m-Daten und dem Einlesen aus xyz:

Der TransDEM-Dialog zum xyz-Import erlaubt ja die Mehrfachauswahl von Dateien. Allerdings ist die String-Länge hier fest und recht knapp. Je nach Pfad zu den xyz-Daten passen da vielleicht 4 bis 6 Dateinamen hinein. Weitere, die man vielleicht noch selektiert hat, werden dann nicht mehr gefunden.

Sind diese 4 bis 6 Dateien eingelesen, bietet TransDEM an, weitere xyz-Dateien hinzuzufügen, oder das bisher gelesene in ein DEM zu wandeln. Beim 32bit-TransDEM muss man nun haushalten. Irgendwann wird man an die Grenzen des 32bit-Adressbereiches stoßen, und zwar eher früher als später.

xyz ist das unmöglichste aller Dateiformate für Höhendaten, nicht nur enorm platzverschwendend, sondern auch ohne jede Meta-Info. Jedes andere Format für DEM weist zumindest die Ausdehnung in Ost- und Nordrichtung aus. Das fehlt bei xyz. TransDEM muss also zunächst das Umfassungsrechteck ermitteln. Das tut es, indem es die xyz-Datei Zeile für Zeile einliest, jede Zeile in einen 3D-Koordinatenpunkt wandelt, diese Koordinaten zwischenspeichert und mit jedem neuen Koordinatenpunkt das Umfassungsrechteck aktualisiert. Die Zwischenspeicherung dieser Punkte schluckt viel Speicher. Das später daraus resultierende DEM wird sehr viel kleiner, weil viel effizienter gespeichert.

Es gilt nun eine Abwägung. Man spart Speicher, wenn man weniger xyz-Dateien einliest und eher in DEM wandelt, dann in einem späteren Schritt die DEM verknüpft. Nur ist das dann eben ein extra Schritt und etwas mehr Arbeit. Haupt-Speicherfresser sind wie gesagt die zwischengespeicherten xyz-Einzelpunkte, nicht das fertige DEM.

In der nächsten TransDEM-Version wird die DEM-Verarbeitung intern etwas effizienter ablaufen. Ich habe noch diverse Optimierungsmöglichkeiten gefunden - und sogar ein Speicherleck. Auch in der 32bit-Version wird dann noch etwas mehr herauszukitzeln sein, aber erst nach abgeschlossenem xyz-Import. Auf dem Braunschweig-Treffen habe ich mit Carsten zudem darüber gesprochen, auch eine 64bit-Version für Zusi zu fertigen, die 32bit-Adressbeschränkung wird dann fallen.

Derzeit ist das größtmögliche DEM allerdings auch in der 64bit-Version noch limitiert, auf 31bit-Adressgröße. Das sind etwa 50000 x 40000 Punkte, beim 1m-DEM 50 x 40 km. Bei der TransDEM-internen Auflösung als Single Precision Floating Point werden dafür etwa 8GB im Hauptspeicher benötigt. Dieses Limit wird durch eine geänderte interne Speicherstruktur fallen, und die Grenzen werden nur noch durch die Systemumgebung bestimmt, insbesondere durch die installierte Hauptspeichergröße und den verfügbaren Swap-Bereich. Dabei ist zu bedenken, dass ein DEM, das irgendwie bearbeitet werden muss, meist mindestens eine weitere Kopie erfordert, bei der derzeitigen Grenze von 8GB also mindestens 16GB benötigt werden. Die sollten physikalisch vorhanden sein, sonst wird es echt langsam. Ob es allerdings sinnvoll ist, so große DEM überhaupt zu laden, steht natürlich auf einem ganz anderen Blatt.

Benutzeravatar
Michael_Poschmann
Beiträge: 19429
Registriert: 05.11.2001 15:11:18
Aktuelle Projekte: Finalisierung Großraum Hagen
Wohnort: Str.Km "1,6" der Oberen Ruhrtalbahn (DB-Str. 2550)

Re: Hochauflösende Höhendaten (1m !) für Nordrhein-Westfalen

#43 Beitrag von Michael_Poschmann »

Kleine Praxis-Anekdote in Ergänzung: Die Auswirkungen der von Roland erwähnten Problematik werden einem nicht immer sofort bewußt.
So habe ich unlängst den Bereich Hagen eingelesen. 60 xyz Dateien auf einen Streich sind des Guten zuviel. Also kleinere "Päckchen" verarbeitet. Die resultierende DEM hatte allerdings leichte Ausfransungen, Modell "Flickenteppich". Da in NRW wöchentlich Aktualisierungen hochgeladen werden, wähnte ich die Datenabdeckung in diesem Bereich noch unvollständig. Erst auf Rücksprache mit den Geo-Fachkollegen stellte sich heraus, dass die Grundabdeckung für unser schönes Bundesland gegeben sei, lediglich Korrekturen würden peu a peu eingearbeitet. Damit wurde offenbar, dass es anscheinend beim Einlesen ein Problem gegeben haben musste. Also noch mal neu ans Werk: Die 60 xyz-Dateien in Einzel-DEM gewandelt und nachfolgend in mehreren Schritten verschmolzen. Voila! In Hagen kann nun munter Landschaftsbau betrieben werden.

Grüße
Michael

Benutzeravatar
Roland Ziegler
Beiträge: 5481
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

Re: Hochauflösende Höhendaten (1m !) für Nordrhein-Westfalen

#44 Beitrag von Roland Ziegler »

Die Grenze bei der Mehrfachselektion wird mit der nächsten Version de-facto fallen, d.h. sie wird so deutlich nach oben verschoben, dass sie in der Praxis nicht mehr auftritt. Allerdings bringt das nur mit der 64bit-Version Arbeitserleichterung, bei den 1m-Daten erreicht man bei 32bit zu schnell Speichergrenzen, und zwar für die Zwischenspeicherung der xyz-Einzelpunkte, nicht beim späteren DEM.

Ich habe das gestern Abend in meiner Laborversion mal ausprobiert, zunächst für die harmlosen 25m-Daten aus Rheinland-Pfalz.

Bild

Da bleibe ich zwar theoretisch noch im 32bit-Adressbereich, würde aber nicht garantieren, dass die 32bit-Version nicht doch an die Speichergrenze stößt.

Anschließend habe ich diese Mehrfachselektion auf alle Dateien für 1m-Daten laufen lassen, mit Arnsberg, was ein Paket etwa mittlerer Größe ist. Der Einlesevorgang ist zäh, dauert ewig, und gegen Ende werden 17GB vereinnahmt, aber es funktioniert. Das finale DEM ist "nur" noch 1,6GB groß. Wohlgemerkt, immer noch bei 1m-Auflösung.

Bild

Für die weiterverarbeitende Werkzeuge sind solche Datenmengen natürlich viel zu viel, man wird um eine Reduktion nicht umhin kommen. Aber mir geht es erst mal um das Prinzipielle, dass die vermeidbaren internen Hürden in TransDEM abgebaut werden, die bei den ursprünglich sehr viel kleineren Datenmengen überhaupt keine Rolle spielten.

Ich bin weiterhin unglaublich fasziniert von dieser beeindruckenden Auflösung. Noch vor wenigen Jahren hätte ich behauptet, braucht kein Mensch, heute kann ich mich kaum satt sehen daran. Mit "Arnsberg" hatte ich schon zu Zusi2-Zeiten experimentiert, begleitend zu Michaels Streckenbauprojekt, ganz zu Anfang mit Top50, dann mit den allseits bekannten SRTM Daten in 3 Bogensekunden, später auch noch mit ASTER. Für Trainz testweise Michaels Gleisgeometrie benutzt, um automatisiert das DEM-Gelände an die Bahntrasseninfrastruktur anzupassen, mit den bekannten Dämmen und Einschnitten als Ergebnis, die keine Entsprechung in der Realität haben.

Bild

Jetzt also 1m. Da bekommen wir die Dämme und Einschnitte frei Haus. Das mit dem Rausrechnen der Brücken funktioniert anscheinend auch nicht immer. Einen Aha-Effekt lösen die Bombenkrater aus, über 70 Jahre alt. Sie zeigen die LIDAR-Möglichkeiten so richtig. In unserer Kulturlandschaft bleibt über diesen Zeitraum kaum ein Quadratmeter unangetastet, bis auf Wälder. Die LIDAR-Nachbearbeitung rechnet die Bäume weg, es kommt der nackte Waldboden heraus. Manche größere Krater wird man auch in der Grundkarte 1:5000 verzeichnet finden, im hochauflösenden Luftbild aber wird man sie nicht erkennen, eben wegen der Bäume. (Photogrammetrische Verarbeitung mal außen vor.)

Auch die Amerikaner haben übrigens begonnen, 1m-LIDAR ins Netz zu stellen. Die Abdeckung ist aber noch sehr gering. Ein eisenbahntechnisch interessanter größerer Bereich ist die östlich Rampe zum Moffat-Tunnel, nordwestlich von Denver, Colorado. Das ist die Gegend, die ich bei meinen allerersten Geodatenversuchen 2001 als Anwendungsbeispiel gewählt hatte. Dort, mit Bahntrassen aus der digitalisierten 1:24000er Karte und damals 30m-Höhendaten haben die grundlegenden Versuche mit dem Absteckrechner stattgefunden.

Bild

Benutzeravatar
Michael_Poschmann
Beiträge: 19429
Registriert: 05.11.2001 15:11:18
Aktuelle Projekte: Finalisierung Großraum Hagen
Wohnort: Str.Km "1,6" der Oberen Ruhrtalbahn (DB-Str. 2550)

Re: Hochauflösende Höhendaten (1m !) für Nordrhein-Westfalen

#45 Beitrag von Michael_Poschmann »

Roland Ziegler hat geschrieben:Der Einlesevorgang ist zäh, dauert ewig, ...
Kein Wunder, das sind Sauerländer, die musst Du treten... :ausheck

Spannend, zumal ich in etwa bei 434400 / 5694800 meine Kindheit verbracht habe, Blick aus dem Fenster auf das "Jägerhaus" am Bahnhof Arnsberg Süd inklusive.
Die Krater sind mir als gruselige Hinterlassenschaften aus grauer Vorzeit in Erinnerung. Als Kind hatte ich immer Sorge, da könnten noch Blindgänger verborgen sein und hochgehen, wenn ich drauftrete. Dann hättet Ihr natürlich jetzt keine virtuelle Nachbildung der Oberen Ruhr, also klarer Fall von "Schwein gehabt". :) Wirklich spannend, diese Effekte nun in den Daten zu sehen.

Grüße
Michael

Benutzeravatar
Frank Wenzel
Beiträge: 4996
Registriert: 06.11.2001 01:13:47
Wohnort: Trier
Kontaktdaten:

Re: Hochauflösende Höhendaten (1m !) für Nordrhein-Westfalen

#46 Beitrag von Frank Wenzel »

Heftig, die Bombentrichter da zu sehen. Tolle Datengrundlage!
Gruß ins Forum, Frank - www.zusi-sk.eu

Benutzeravatar
Wolfgang Hüttner
Beiträge: 599
Registriert: 14.03.2003 15:10:13
Aktuelle Projekte: Netz Nordbaden, Bergheim - Bad Pyrmont
Wohnort: Neckarsteinach

Re: Hochauflösende Höhendaten (1m !) für Nordrhein-Westfalen

#47 Beitrag von Wolfgang Hüttner »

Hallo Roland,

haben Deine Erkenntnisse zum Speicherplatzbedarf auch etwas mit meinem Problem zu tun?

Zur Erläuterung und als Hinweis für alle anderen:
Beim ZUSI-Treffen habe ich am Sonntagnachmittag noch ein Problem beim Geländeformerlauf mit Roland diskutiert.
Beim Versuch die Grundplatte für das Modul Bergheim zu erzeugen entstand bei mir das Problem, dass der Geländeformer keine zusammenhängenden Meshsubsets erzeugt, sondern ein wild zerklüftetes Gelände wie im nachstehenden Screenshot zu sehen. Basis für das DEM waren die 1m - Daten, für den Geländeformerlauf reduziert auf ein 10m Raster.
Bild

Hat eigentlich schon jemand anderes Grundplatten mit diesen 1m-Daten erzeugt?
Waren dort die Meshsubsets zusammenhängend?

Gruß
Wolfgang

Benutzeravatar
Roland Ziegler
Beiträge: 5481
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

Re: Hochauflösende Höhendaten (1m !) für Nordrhein-Westfalen

#48 Beitrag von Roland Ziegler »

Wolfgang Hüttner hat geschrieben:haben Deine Erkenntnisse zum Speicherplatzbedarf auch etwas mit meinem Problem zu tun?
Das denke ich nicht. Was ich da im Moment in den Innereien von TransDEM einbaue, ist im Wesentlichen eine Effizienzsteigerung für die neuen hochauflösenden Höhendaten. Vergleicht man mit den bisherigen 60m- oder 30m- Daten, so liegen hier ja 10er-Potenzen dazwischen. Das meiste, was sich deswegen bisher verändert hat, betrifft das Einlesen der nicht-nativen Datenformate (wobei "nativ" in TransDEM bedeutet: MicroDEM .dem, Version 1 bis 4). Zwar ändert sich auch die interne Speicherrepresentation des DEM, und die wird ebenso im GF genutzt (selbe Bibliothek), aber für die beobachtete merkwürdige Mesh-Aufteilung sehe ich keinen Zusammenhang mit dem DEM. Doch ich muss es erst analysieren.

Benutzeravatar
Wolfgang Hüttner
Beiträge: 599
Registriert: 14.03.2003 15:10:13
Aktuelle Projekte: Netz Nordbaden, Bergheim - Bad Pyrmont
Wohnort: Neckarsteinach

Re: Hochauflösende Höhendaten (1m !) für Nordrhein-Westfalen

#49 Beitrag von Wolfgang Hüttner »

Hallo Roland,

das Problem mit den Meshsubsets hängt auf jeden Fall mit dem DEM zusammen. Ich habe jetzt versuchsweise nochmal die Grundplatte mit dem SRTM-DEM erstellt, dabei tritt der Effekt nicht auf.

Gruß
Wolfgang

Benutzeravatar
Roland Ziegler
Beiträge: 5481
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

Re: Hochauflösende Höhendaten (1m !) für Nordrhein-Westfalen

#50 Beitrag von Roland Ziegler »

Wolfgang Hüttner hat geschrieben:das Problem mit den Meshsubsets hängt auf jeden Fall mit dem DEM zusammen. Ich habe jetzt versuchsweise nochmal die Grundplatte mit dem SRTM-DEM erstellt, dabei tritt der Effekt nicht auf.
Danke für den Hinweis. Nachdem meine TransDEM-Liste jetzt weitgehend abgearbeitet ist, werde ich in den nächsten Tagen wohl Zeit finden, dies im GF zu untersuchen.

Benutzeravatar
Roland Ziegler
Beiträge: 5481
Registriert: 04.11.2001 22:09:26
Wohnort: 32U 0294406 5629020
Kontaktdaten:

Re: Hochauflösende Höhendaten (1m !) für Nordrhein-Westfalen

#51 Beitrag von Roland Ziegler »

Nochmal zurück zu den NRW 1m-Höhendaten: https://www.opengeodata.nrw.de/produkte ... /dgm/dgm1/" target="_blank

Hier bestand immer noch das Problem, wie man benachbarte Gebiete findet, denn eine direkte Übersichtskarte gibt es nicht.

Doch jetzt ist klar, wie das Verzeichnis aufgebaut ist. Die Dateien sind sortiert nach Gemeindegrenzen. Lag eigentlich nahe, aber die letzte Bestätigung war die Nummer vor dem Namen in der Datei. Das ist der offizielle Gemeindeschlüssel, also z.B.
dgm1_05111000_Düsseldorf_EPSG4647_XYZ.zip
ist (logischerweise) Düsseldorf und Düsseldorf hat den bundesweiten Gemeindeschlüssel 05111000.

Und mit dem Wissen um die Gemeindegrenzen kann man sich im Geoportal.NRW die Gemeindegrenzen und die Gemeindenamen anzeigen lassen und findet so die Nachbargebiete:
Bild

Eigentlich ganz simpel... :hat2
Zuletzt geändert von Roland Ziegler am 22.02.2018 13:06:01, insgesamt 1-mal geändert.

Benutzeravatar
Oliver Lamm
Beiträge: 3073
Registriert: 04.01.2002 15:02:17
Aktuelle Projekte: Aachen - Neuss für Zusi3
Wohnort: Essen
Kontaktdaten:

Re: Hochauflösende Höhendaten (1m !) für Nordrhein-Westfalen

#52 Beitrag von Oliver Lamm »

Moin,
der Link hat sich geändert:

https://www.opengeodata.nrw.de/produkte ... /dgm1_xyz/

Oli
Oliver Lamm
mail(AT)oliverlamm(DOT)de

Benutzeravatar
Michael_Poschmann
Beiträge: 19429
Registriert: 05.11.2001 15:11:18
Aktuelle Projekte: Finalisierung Großraum Hagen
Wohnort: Str.Km "1,6" der Oberen Ruhrtalbahn (DB-Str. 2550)

Re: Hochauflösende Höhendaten (1m !) für Nordrhein-Westfalen

#53 Beitrag von Michael_Poschmann »

Ein deutlich komfortablerer Link findet sich hier: Klick

Unter "Open Data Download" kann man sich den gewünschten Ausschnitt per Karte zusammenstellen.

Grüße
Michael

Antworten