Gemeinsam mit der Stadt München haben wir die Migration der Straßenbeleuchtungsdaten erfolgreich abgeschlossen. Die Stadt hatte uns beauftragt, die Daten in ein zukunftssicheres Format zu wandeln, um die Flexibilität für die nächsten Jahrzehnte sicherzustellen.

Das Projekt wurde in Zusammenarbeit mit der it@M durchgeführt, die bereits seit vielen Jahren unsere Software RoSy für die Erfassung der Straßenbeleuchtungsdaten einsetzt. Da der Support für dieses System zu Ende 2023 ausläuft, entschied man sich für die Durchführung des Migrationsprojekts.

Das Ziel des Projekts war es, die bereits erfassten Daten in ein Format zu wandeln, welches auch in einem zukünftigen System verwendet werden kann. Die Wahl fiel auf Esri Shapefile, da es ein Quasi-Standard in der Welt der Geoinformatik ist und von allen gängigen Geo-Anwendungen unterstützt wird. Damit ist die Stadt München für eine Ersetzung des aktuellen Systems gerüstet.

Während des Projektverlaufs sind zwar einige Herausforderungen aufgetreten, jedoch konnten sie durch die enge Zusammenarbeit und den direkten Draht zwischen den Projektbeteiligten schnell und konstruktiv gelöst werden. Das Projekt wurde im Zeitplan umgesetzt und der Kunde zeigte sich äußerst zufrieden mit der Zusammenarbeit:

„Auch von meiner Seite möchten ich mich ganz herzlich für die Zusammenarbeit mit Ihnen und den anderen Beteiligten bei M.O.S.S. bedanken. Die Umstände sind bei der Stadt speziell und sicherlich für M.O.S.S. als mittelständisches Unternehmen eine große Herausforderung. Dennoch ging alles gut über die Bühne. Danke nochmal von meiner Seite, für Ihre Bereitschaft, diese Herausforderungen mit großer Flexibilität und großem Engagement anzunehmen und zu überwinden.“
– Anwendungsmanager it@M

M.O.S.S. war der richtige Partner für das Projekt, da wir bereits viele erfolgreiche Migrationsprojekte durchgeführt haben und in diesem Fall aufgrund des proprietären RoSy-Formats unsere Kompetenz gefragt war.

Das Projekt war ein herausragendes Beispiel dafür, wie man eine komplexe Aufgabe mit geeignetem Personal und guter Kommunikation reibungslos über die Bühne bringt. Wir bedanken uns bei der it@M und der Stadt München für die Zusammenarbeit und das Vertrauen in unsere Expertise.

--

M.O.S.S. bietet jahrzehntelange Erfahrung beim Thema Datenmigration – wir unterstützen auch Sie bei Ihrem nächsten Projekt! Dabei spielt es keine Rolle, welches Ausgangs- und Zielsystem Sie einsetzen. Kommen Sie einfach auf uns zu.

Der Komfort-Import-Assistent bietet eine schnelle und unkomplizierte Möglichkeit, Geo-Dateien in unterschiedliche Zielcontainer zu importieren. In diesem Artikel zeigen wir Ihnen die Vorteile der neuen Funktionen.

Neue Funktionen im WEGA-Client

Im WEGA-Client können lokale Geo-Dateien direkt zur Nutzung in einer WEGA-Sitzung importiert werden. Dies entspricht der Funktion „Geo-Datei laden in eine dauerhafte Ebene“ aus dem WEGA 9 – Client, bietet aber viele Vorteile:

Es besteht die Möglichkeit, den Import per Drag & Drop von Geo-Dateien in die Karte zu starten, mehrere Dateien auf einmal zu importieren und optional im Inhaltsbaum zu gruppieren. Wie auch im WEGA 9 – Client können die Symbolisierung und die Beschriftung wahlweise vor oder nach dem Import angepasst werden. Der neue Komfort-Import-Assistent bietet hierfür aber einen weitaus mächtigeren Funktionsumfang.

Der Assistent für den Zielcontainer WEGA-Client beinhaltet dabei verschiedene Schritte wie die Dateiauswahl, Konfiguration des Imports und Zusammenfassung des Imports.

Ergebnis eines Imports ist immer ein Geodatendienst vom Typ OGC API Feature, auf den über die Funktion „Importe verwalten“ auch andere WEGA-Nutzer zugreifen können. Damit eröffnet sich eine ganz neue Form der Zusammenarbeit im Team.

Import nach novaFACTORY

Auch in die novaFACTORY-Datenhaltung können lokale Geo-Dateien nun bequem und einfach für die dauerhafte Nutzung importiert werden. Besonders in Fällen, in denen der Nutzer keinen Zugriff auf das novaFACTORY-Import-Verzeichnis hat oder die zu importierenden Dateien nicht oder nur teilweise in der novaFACTORY-Dateinamensyntax für Import-Dateien vorliegen, bietet der Komfort-Import-Assistent eine gute Alternative zum batchorientierten Import. Bei Einhaltung der novaFACTORY-Dateinamenssyntax erfolgen im Komfort-Import automatische Zuordnungen z.B. von Produkt oder Ebene.

Auch wenn das Zielmodell und das Quellmodell nicht übereinstimmen, können Felder von Vektordaten frei zugeordnet werden. Der Assistent für den Zielcontainer novaFACTORY bietet eine Auswahl der zu importierenden Dateien, eine Dateiübersicht zum Upload, die Wahl des novaFACTORY-Produkts sowie der novaFACTORY-Ebene und des Blattschnitts inklusive Voransicht der zu importierenden Daten und einen Feldzuordnungsdialog. Alle diese Komponenten zeigen den jeweiligen Status der notwendigen Zuordnungen mit intuitiven graphischen Symbolen an. Vor dem Start des Imports wird der Dialog mit einer Zusammenfassung abgeschlossen.

Die folgenden Videos zeigen die neuen Funktionen des Komfort-Import-Assistenten:

Komfort-Import-Assistent mit Ziel WEGA-Client

Komfort-Import-Assistent mit Ziel Datenhaltung novaFACTORY aus novaFACTORY Client

Komfort-Import-Assistent mit Ziel Datenhaltung novaFACTORY per Drag and Drop

Ausblick

Aktuell unterstützt der Komfort-Import-Assistent Esri Shapefile und wird künftig um weitere Vektor- und Rasterformate wie zum Beispiel GeoPackage oder TIFF erweitert. Außerdem werden in Zukunft neben den Zielcontainern WEGA-Client und novaFACTORY auch weiter Import-Ziele wie die WEGA-EMS-Datenhaltung unterstützt.

Wenn Sie mehr über den neuen Komfort-Import-Assistenten erfahren möchten, kontaktieren Sie uns für weitere Informationen. Wir sind gerne bereit, Ihnen bei Fragen oder Anliegen weiterzuhelfen.

Bei 3D Stadt- und Landschaftsmodellen gibt es oft sich wiederholende Objekte wie Spielplätze, Haltestellenschilder oder Mülleimer. Diese können wie andere Modelle per Hand erstellt werden, doch das bedeutet einen hohen Aufwand. Zudem können die Dateien sehr groß werden. Eine CityGML Symbolbibliothek schafft hier Abhilfe.

Seit dem Herbstrelease 2022 ist es möglich, solche Objekte anhand dieser Symbolbibliothek mit der novaFACTORY Toolbox zu erzeugen. In novaFACTORY wurde dazu beim CityGML Export ein automatischer Schalter implementiert. Dieser prüft beim Export, ob eine Symbolbibliothek an einer definierten Stelle vorhanden ist. Findet er keine, ignoriert er die Symbole. Liegt jedoch eine vor, werden die Namen in der Bibliothek mit den Namen der Platzhalter verglichen. Wird eine Übereinstimmung gefunden, so wird das Symbol einmal explizit und X-mal implizit gesetzt. Implizit bedeutet, dass auf das explizite Symbol, welches die Geometrie beinhaltet, verlinkt wird. Dadurch wird Speicher gespart, da die Geometrie nur einmal pro Symbol und Gebiet vorliegt und nicht X-fach.

Wie funktioniert die Erstellung von Symbolreferenzen?

Als erstes muss mittels FEATURE3D ein Platzhalter für eine Symbolreferenz definiert werden. Dies kann über eine separate Neuproduktion erfolgen und beim späteren Export als eigener Layer im WEGA-3D behandelt werden. Dies ist jedoch nur eine Möglichkeit. Falls die Symbole in ein bestehendes Produkt eingegliedert werden sollen, funktioniert dies auch über unseren Update-Prozess oder über einen Workflow. Die gewünschten Objekte müssen also gefiltert bzw. angegeben werden und über die AttrDef neu definiert als Platzhalter aktualisiert werden.

Bei der letzten Methode sollte jedoch beachtet werden, wofür das Produkt gedacht ist, da eine AdV-konforme Abgabe der Symbole nicht gewährleistet ist.

Abbildung 1 zeigt den aktuellen Stand in vielen Datenbeständen: Ein Stromleitungsmast wird nur als eine einfache Säule dargestellt. Derartige Objekte müssen gefiltert oder angegeben werden, damit der Prozess weiß, welche Objekte angepasst werden sollen.

In Abbildung 2 ist eine beispielhafte Überlagerung zu erkennen. Hier kann geprüft werden, ob das Symbol auch lagerichtig zu der vorherigen 3D Ausprägung ist (links richtig, rechts falsch).

Abbildung 2: 3D Symbol ÜberlagerungSind nun alle Vorkehrungen richtig getroffen worden, kann das CityGML-Produkt exportiert werden. Dabei werden automatisch die Symbole pro Kachel einmal explizit gespeichert und alle weiteren implizit.

Abbildung 3 zeigt die fertigen Beispiele eines mittleren Stromleitungsmasten und eines Windrads.

Fazit

Damit ist es nun möglich, automatisiert über z.B. den Update-Prozess neue oder geänderte Geometrien bzw. Symbole zu erzeugen. Damit lässt sich das 3D Stadtmodell anreichern, und es werden Objekte geschaffen, um Sensoren oder Verknüpfungen zu anderen Datenquellen herzustellen.

Insgesamt ist die CityGML Symbolbibliothek eine effektive Möglichkeit, um Zeit und Aufwand bei der Erstellung von 3D-Modellen zu sparen. Dank des automatischen Schalters bei der Exportfunktion und der Möglichkeit, Symbole zu referenzieren, wird das Erstellen von 3D-Modellen noch einfacher und effizienter.

--

Sie möchten mehr über unser Angebot im Bereich 3D erfahren? Dann treffen Sie uns beim 3D-Forum in Lindau!

Wir werden dort vom 09. bis 10. Mai 2023 mit einem Stand auf der Firmenausstellung vertreten sein und auch einen Workshop halten:

Generative Verfahren zur automatischen Anreicherung des 3D-Stadtmodells
Mittwoch, 10. Mai 2023 | 13:45 - 14:45 Uhr

JETZT ANMELDEN

Bei den meisten aktuellen Projektionen ist die Reihenfolge der Koordinatenachsen x,y. Es gibt aber auch einige ältere Projektionen, bei denen die Reihenfolge der Koordinatenachsen y,x ist. Relevant für Daten aus Deutschland sind hier insbesondere die ältere DHDN-GK-Projektion EPSG:31466-EPSG:31469. Hier ist die Reihenfolge der Koordinatenachsen y,x. Bei der neueren DHDN-GK-Projektion EPSG:5676 - EPSG:5680 ist die Reihenfolge der Koordinatenachsen x,y.

Die ArcGIS-JS-API, auf der der WEGA 10 Client aufsetzt, berücksichtigt die in der EPSG-Datenbank hinterlegte Reihenfolge der Koordinatenachsen einer Projektion nicht. Es wird vielmehr davon ausgegangen, dass die Reihenfolge der Koordinatenachsen einer Projektion immer x,y ist. Der M.O.S.S. - SDI-Provider (MSP) und der dort integrierte GeoServer erwarten bei räumlichen Abfragen via BBOX, die in der EPSG-Datenbank hinterlegte Reihenfolge der Koordinatenachsen.

Dies führt dazu, dass räumliche BBOX-Anfragen mit EPSG:31466 - EPSG:31469 im WEGA 10 Client falsch interpretiert werden und deshalb keine Daten in der Karte zu sehen sind.

Um dies zu umgehen, ist es möglich im Datenverzeichnis des MSP im Unterverzeichnis user_projections mit Hilfe der Datei epsg_overrides.properties bestimmte Projektionen via WKT-String zu überschreiben. So kann zum Beispiel folgender WKT-String für EPSG:31466 aus der EPSG-Datenbank:

PROJCS["DHDN / 3-degree Gauss-Kruger zone 4",
GEOGCS["DHDN",
DATUM["Deutsches Hauptdreiecksnetz",
SPHEROID["Bessel 1841", 6377397.155, 299.1528128,
AUTHORITY["EPSG","7004"]],
TOWGS84[612.4, 77.0, 440.2, -0.054, 0.057, -2.797, 2.55],
AUTHORITY["EPSG","6314"]],
PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]],
UNIT["degree", 0.017453292519943295],
AXIS["Geodetic latitude", NORTH],
AXIS["Geodetic longitude", EAST],
AUTHORITY["EPSG","4314"]],
PROJECTION["Transverse_Mercator", AUTHORITY["EPSG","9807"]],
PARAMETER["central_meridian", 12.0],
PARAMETER["latitude_of_origin", 0.0],
PARAMETER["scale_factor", 1.0],
PARAMETER["false_easting", 4500000.0],
PARAMETER["false_northing", 0.0],
UNIT["m", 1.0],
AXIS["Northing", NORTH],
AXIS["Easting", EAST],
AUTHORITY["EPSG","31468"]]

durch folgenden Eintrag in der epsg_overrides.properties überschrieben werden:

31466=PROJCS["DHDN / 3-degree Gauss-Kruger zone 4", \
GEOGCS["DHDN", \
DATUM["Deutsches Hauptdreiecksnetz", \
SPHEROID["Bessel 1841", 6377397.155, 299.1528128,
AUTHORITY["EPSG","7004"]], \
TOWGS84[612.4, 77.0, 440.2, -0.054, 0.057, -2.797, 2.55], \
AUTHORITY["EPSG","6314"]], \
PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]], \
UNIT["degree", 0.017453292519943295], \
AXIS["Geodetic longitude", EAST], \
AXIS["Geodetic latitude", NORTH], \
AUTHORITY["EPSG","4314"]], \
PROJECTION["Transverse_Mercator"], \
PARAMETER["central_meridian", 12.0], \
PARAMETER["latitude_of_origin", 0.0], \
PARAMETER["scale_factor", 1.0], \
PARAMETER["false_easting", 4500000.0], \
PARAMETER["false_northing", 0.0], \
UNIT["m", 1.0], \
AXIS["Easting", EAST], \
AXIS["Northing", NORTH], \
AUTHORITY["EPSG","31468"]]

In den beiden WKT-Projektionen sind lediglich die Definitionen für AXIS in ihrer Reihenfolge vertauscht.

Die Notation zur Definition einer Projektion ist folgende: <epsg-code>=<wkt-string>

Es wird empfohlen, den WKT-String einzeilig zu definieren. In diesem Beispiel ist der WKT-String zur besseren Lesbarkeit formatiert. Zeilenumbrüche werden durch das Zeichen \ am Ende einer jeden Zeile gekennzeichnet. In der letzten Zeile befindet sich kein Zeilenumbruch. Wer auf die Unterstützung der ältere EPSG-Codes EPSG:31466-31469 mit der Achsenreihenfolge y,x verzichten kann, möge bitte die neueren EPSG-Codes EPSG:5676 - EPSG:5680 mit der Achsenreihenfolge x,y in WEGA verwenden.