Digitaler Gestaltplan Potsdam

Transkript

1 Projektdokumentation Digitaler Gestaltplan Potsdam Das Vorhaben Digitaler Gestaltplan Potsdam wurde aus Mitteln des Europäischen Fonds für Regionale Entwicklung gefördert.

2 Bearbeitung: Dr.-Ing. Lutz Ross virtualcitysystems GmbH Cicerostr Berlin Stefanie Buchta Landeshauptstadt Potsdam Hegelallee 6-10, Haus Potsdam Ansprechpartner: Erik Wolfram Landeshauptstadt Potsdam Hegelallee 6-10, Haus Potsdam

3 Inhaltsverzeichnis Abbildungsverzeichnis... II Tabellenverzeichnis... II Einleitung Digitaler Gestaltplan Potsdam Datenmodell Flächenobjekte Punktobjekte Datenhaltung und Datenbankmodell Aktualisierungs- und Fortführungsworkflows Aktualisierung Bestandsgebäude Aktualisierung und Erweiterungen des Gestaltplanes Erfassung und Aktualisierung von Planungen Topologie und Semantikprüfung Integration als WMS/WFS-Dienste in die Potsdamer GDI LoD1 Stadtmodell Potsdam Datenmodell Datenhaltung Fortführungskonzept Export und Visualisierung des 3D-Stadtmodells KML/Collada Export und Visualisierung in Google Earth Export im CityGML Format Zusammenführung Gestaltplan und 3D-Stadtmodell Übersicht der Daten, Softwarekomponenten und Skripte I

4 Abbildungsverzeichnis Abbildung 1: Datenbankmodell des Digitalen Gestaltplanes... 5 Abbildung 2: Verschmelzen eines Grundrisses mit der Nachbarfläche... 6 Abbildung 3: In Gelb ist die Erweiterung einer Straßenfläche dargestellt. Das Attributeingabefenster öffnet sich nach Abschluss der Flächenerfassung automatisch (vgl. Grundeinstellungen für die Bearbeitung) Abbildung 4: Ablaufdiagramm Erfassung von Planungen Abbildung 5: Beispielhafte Abgrenzung eines Planungsraumes Abbildung 6: Integration eines Plangebietes durch Bildung des Flächenumringes, Ausstanzen des Plangebietes und Integration der Planung Abbildung 7: Fortführungsworkflow LoD1-Stadtmodell und Konzept LoD2 Fortführung Abbildung 8: ArcGIS Toolbox zur Datenprüfung und -Filterung Abbildung 9: Benutzeroberfläche shape2citygml-konverter Schritt Abbildung 10: Benutzeroberfläche shape2citygml-konverter Schritt Abbildung 11: Veröffentlichung in Google Earth Abbildung 12: Darstellungsoptionen für den KML/Collada-Export Abbildung 13: Konfiguration von Balloons zur Ausgabe von Attributen in Google Earth Abbildung 14: Exporteinstellungen der ausgelieferten Beispielausspielung Abbildung 15: Koorindatenreferenzsysteme einstellen Abbildung 16: Exportdialog des Importer/Exporters Abbildung 17: Beispielhafte Integration von Plangebäuden, Planzeichnung und Plangebietsabgrenzungen in LandXplorer Studio Professional Tabellenverzeichnis Tabelle 1: Objektklassen und Geometrietypen des digitalen Gestaltplanes Potsdam... 2 Tabelle 2: Attribute der Flächenobjekte... 2 Tabelle 3: Erläuterung der Werte des Attributes GS_ZUSATZ... 3 Tabelle 4: Attributbezeichnung und Erläuterung zu den Baumstandorten... 4 Tabelle 5: Erwartete Attributwerte nach Datenaufbereitung (entspricht Datenabgabe vom ). 16 Tabelle 6: Prüf- und Filterbedingungen II

5 Digitaler Gestaltplan und LoD1- Stadtmodell Potsdam Einleitung Gegenstand des Vorhabens Digitaler Gestaltplan Potsdam im Rahmen der EFRE Förderung des Landes Brandenburg zum Aufbau der Geodateninfrastruktur Brandenburg war die Konvertierung und Qualifizierung des digitalen Gestaltplanes Potsdam, der Aufbau eines 3D-Stadtmodells im LoD1 auf Basis der ALK-Daten nach VALK-Richtlinie, sowie die Entwicklung und Bereitstellung von Webdiensten, Workflows und Softwarekomponenten zur Fortführung und Integration der beiden Datensätze. Im Ergebnis wurden die Voraussetzungen für einen kontinuierliche Fortführung und Nutzung der beiden genannten Datensätze sowie Tools und Workflows für eine öffentliche Bereitstellung geschaffen. Die Projektdokumentation gliedert sich in vier Abschnitte. Im ersten Abschnitt wird der Digitale Gestaltplan Potsdam beschrieben. Er umfasst eine Datenmodellbeschreibung, eine Dokumentation der Bearbeitungsmöglichkeiten, sowie eine Dokumentation der veröffentlichten Dienste. Abschnitt zwei hat das LoD1-Stadtmodell auf Basis der ALK nach VALK-Richtlinie zum Inhalt. Insbesondere werden die Voraussetzungen und die Workflows zur Datenkonvertierung und zur Fortführung des LoD1- Stadtmodells, sowie Export und Visualisierungsworkflows auf Basis von Google Earth beschrieben. Der dritte Abschnitt behandelt die Zusammenführung der beiden Datensätze auf Basis der Datenbankschnittstelle des LandXplorer Studio Professionals. Abschnitt vier enthält eine zusammenfassende Übersicht der Skripte und Tools, die im Vorhaben entwickelt wurden. 1

6

7 1. Digitaler Gestaltplan Potsdam Ziel des Arbeitspaketes Digitaler Gestaltplan Potsdam war die Überführung und Aktualisierung des digitalen Gestaltplanes der Stadt Potsdam. Der Digitale Gestaltplan ist ein Planwerk zur Darstellung von städtebaulichen Planungen und Konzepten. Er wurde über mehrere Jahre aufgebaut und anlassbezogen erweitert. Die Datenhaltung und Bearbeitung erfolgte dabei in unterschiedlichen CAD-Systemen auf Basis unterschiedlicher Datengrundlagen (ALK, Stadtkarte, Luftbilder, Städtebauliche Konzepte, etc.) zu unterschiedlichen Zeitpunkten und durch unterschiedliche Bearbeiter. Um eine Bearbeitung, Fortführung und Ausgabe im bisher verwendeten CAD-System zu ermöglichen, wurde zudem eine Kachelstruktur definiert. Als Folge der heterogenen Datenquellen, der Kachelstruktur, unterschiedlicher Bearbeiter und Bearbeitungszeitpunkte wies der Digitale Gestaltplan zunehmend Inkonsistenzen auf, die die effiziente Bearbeitung und Fortführung erschwerten. So bildeten die Inhalte des Gestaltplanes in Teilen auf Grund der verschiedenen Datengrundlagen und Bearbeitungszeitpunkte nicht mehr die Realität ab, innerhalb der CAD-Kacheln wurden unterschiedliche Layerbezeichnungen verwendet und eine blattschnittfreie Darstellung war nicht möglich. Das Ziel des Teilvorhabens Digitaler Gestaltplan Potsdam war die Überführung der Daten in einen blattschnittfreien, klar definierten Geodatensatz, der die Fortführung und zukünftige Nutzung des Digitalen Gestaltplanes ermöglicht. In diesem Zuge erfolgte zugleich eine Aktualisierung der Inhalte durch den Fachbereich Stadtplanung und Bauordnung. Durch die genannten, historisch bedingten Inkonsistenzen des Gestaltplanes, wurde in weiten Teilen eine komplette Neuerfassung, bzw. Aktualisierung nötig, die in Abstimmung mit dem Auftraggeber erfolgte. Als Ergebnis des Vorhabens liegt der Digitale Gestaltplan jetzt als Geodatensatz in der Stadtverwaltung vor und kann dort zukünftig effizient fortgeführt und erweitert werden. Damit wurde auch die Voraussetzung zur Einbettung des Digitalen Gestaltplanes in die Potsdamer Geodateninfrastruktur geschaffen und der Digitale Gestaltplan ist seit August 2011 als Webmapping-Anwendung und als WMS-Dienst öffentlich erreichbar Datenmodell Das Datenmodell des digitalen Gestaltplanes orientiert sich am Layermodell der bisherigen CAD Daten. Grundsätzlich ist geometrischen zwischen zwei Objekttypen zu unterscheiden: Punkte und Flächen. Das thematische Modell differenziert in 10 Objektklassen, davon sind 9 als Flächenobjekt und eine als Punktobjekt definiert. Die Flächenobjekte bilden im Flächenschluss den eigentlichen Gestaltplan ab, die Punktobjekte (Baumstandorte) dienen im Wesentlichen der grafischen Ausgestaltung. Die Tabelle 1 gibt einen Überblick über die spezifizierten Objektklassen. 1

8 Tabelle 1: Objektklassen und Geometrietypen des digitalen Gestaltplanes Potsdam Objektklasse (Type) CLASS_ID Geometrietyp Bahnflaechen 1 Polygon Gewaesser 2 Polygon Oeffentliche Gruenflaeche 3 Polygon Private Gruenflaeche 4 Polygon Strasse 5 Polygon Wege und Freiflaechen 6 Polygon Bestand 7 Polygon Gesicherte Planung 8 Polygon Langfristige Planung 9 Polygon Baum 10 Point Nicht klassifiziert 99 Polygon Flächenobjekte Die Flächenobjekte (Tabelle 1: CLASS_ID 1-9) bilden im Flächenschluss den eigentlichen Gestaltplan Potsdam ab. Sie definieren für jede Fläche innerhalb der Planausdehnung einen Flächentyp, der durch die in Tabelle 2 gelisteten Attribute näher beschrieben wird. Tabelle 2: Attribute der Flächenobjekte Attributbezeichnung Beschreibung Datentyp OBJECTID Fortlaufende Objekt ID, wird von ArcGIS verwaltet Integer SHAPE Geometrietyp Polygon, wird von ArcGIS verwaltet String Gebäudekennzeichen nach VALK Richtlinie, wird für String OBJEKTNAME Bestandsgebäude vergeben TYPE Klarname des Flächentyps gemäß Tabelle 1 String CLASS_ID Klassen ID der Objektklasse Integer PA_ID Planungsgebiets ID zur Zuordnung der Plangebiete Integer Anzahl der Vollgeschosse, gilt nur für geplante Gebäude Integer ANZ_VG (Gesicherte Planung und Langfristige Planung) Gebäudehöhe als Dezimalzahl, gilt nur für geplante Gebäude Double GEB_HOEHE (Gesicherte Planung und Langfristige Planung) GS_ZUSATZ Zusatz zur Gebäudeausgestaltung String Shape_Length Länge des Polygonzuges Double Shape_Area Fläche des Polygons Double Nicht alle Objektklassen erfordern die vollständige Angabe aller Attribute. Grundsätzlich sind die Attribute TYPE, CLASS_ID, PA_ID für alle Objektklassen fortzuführen. Das Attribut OBJEKTNAME ist nur für Bestandsgebäude und die Attribute ANZ_VG, GEB_HOEHE, GS_ZUSATZ nur für Planungen (CLASS_ID 8 und 9) fortzuführen. Die Attribute OBJETID, SHAPE, Shape_Lenght und Shape_Area werden von ArcGIS automatisch verwaltet. 2

9 Das Attribut TYPE enthält den Klarnamen der Flächennutzung nach Tabelle 1 und das Attribut CLASS_ID den zugeordneten ID-Code. Das Attribut PA_ID wird für Objekte vergeben, die innerhalb eines Plangebietes liegen. Dies ermöglicht die Zuordnung der Objekte zu Plangebieten für die in einer separaten Tabelle weitere Informationen (Gebietsbezeichnung, Bearbeiter, Arbeitsstand) vorliegen. Dadurch wird einerseits die Dokumentation von Bearbeitungsschritten ermöglicht, andererseits kann das Attribut verwendet werden, um über eine Objektaggregation die Plangebietsgrenzen abzuleiten oder um in Zukunft eine Verlinkung mit weiterführenden Planungsinformationen (Webseiten, Auskunftssysteme) einzurichten. Das Attribut OBJEKTNAME wird aus den ALK Gebäudedaten übernommen. Durch das im Aktualisierungsund Bearbeitungsworkflow beschriebene Verfahren wird eine automatische Übernahme des Attributwertes erreicht. Über das Attribut ist eine Verknüpfung zu einer Tabelle mit weiteren Attributen der ALK möglich. Die Attribute ANZ_VG, GEB_HOEHE, GS_ZUSATZ sind für eine 3D-Darstellung der geplanten Bebauung im 3D-Stadtmodell und als Information zur Ausgestaltung relevant. Während die ersten beiden Attribute selbsterklärend sind und nummerische Werte als Eingabe erwarten, ist das Attribut GS_ZUSATZ eingeführt worden, um zusätzliche Ausgestaltungsinformationen zu dokumentieren. Bisher wurden die in Tabelle 3 gelisteten Werte definiert, die bei Bedarf erweitert werden können. Tabelle 3: Erläuterung der Werte des Attributes GS_ZUSATZ Attributwert "+D" "+Staffel" Durchgang Bedeutung Dachgeschoss vorgesehen Staffelgeschoss vorgesehen Durchgang vorgesehen Alle Flächenobjekte zusammen bilden im Flächenschluss den Gestaltplan in seiner aktuellen Ausdehnung ab. Das bedeutet, dass in der Regel keine Löcher oder Überlappungen zwischen den Objekten existieren. Der Flächenschluss wurde durch Bildung einer Topologie geprüft und Topologiefehler behoben. Ausnahmen existieren nur an 7 Bestandsgebäuden, die sich geringfügig überlappen. Dieser Fehler wurde toleriert, um die Kongruenz mit den Katasterdaten zu erhalten Punktobjekte Die Punktobjekte bilden Baumstandorte ab und dienen insbesondere der grafischen Ausgestaltung des Gestaltplanes, indem sie einen Eindruck des raumbildenden Grüns in der Stadt vermitteln. Sie weisen die in Tabelle 4 aufgeführten Attribute auf. 3

10 Tabelle 4: Attributbezeichnung und Erläuterung zu den Baumstandorten Attributbezeichnung Beschreibung OBJECTID Fortlaufende Objekt ID, wird von ArcGIS verwaltet Shape Geometrietyp Point, wird von ArcGIS verwaltet PKTNR Aus der Stadtkarte übernommene Punktnummer PKTX Aus der Stadtkarte übernommener X-Wert PKTY Aus der Stadtkarte übernommener Y-Wert PKTZ Aus der Stadtkarte übernommener Z-Wert Aus der Stadtkarte übernommene Klassifizierung in Laub- und GGARTBEZ Nadelbäume CLASS_ID Klassen ID der Objektklasse gemäß Tabelle 1 PA_ID Planungsgebiets ID zur Zuordnung der Plangebiete QUELLE Kodierte Datenquelle Da die meisten Bäume aus der Stadtkarte übernommen wurden, werden die dort enthaltenen Informationen PKTNR, PKTX, PKTY, PKTZ, GGARTBEZ übernommen. Das Attribut CLASS_ID verweist auf die Objektklasse nach Tabelle 1, das Attribut PA_ID ist analog wie bei den Flächenobjekten fortzuführen und das Attribut QUELLE dient als Referenz auf die Datenherkunft. Der Wert 1 steht für Herkunft aus der Stadtkarte, der Wert 2 für Herkunft aus dem alten Gestaltplan, bzw. für im Rahmen der Plandarstellung hinzugefügte Bäume Datenhaltung und Datenbankmodell In Absprache mit dem Auftraggeber wurde eine ESRI Enterprise-Geodatabase auf Basis von Oracle als Datenhaltungskomponente definiert. Dies erleichtert einerseits die Datenhaltung vor Ort, weil alle Informationen in einem Ordner integriert sind, der an einem zentralen Platz im Netzwerk abgelegt werden kann, so dass eine gemeinsame Bearbeitung, bzw. ein gemeinsamer Zugriff, durch unterschiedliche Nutzer stattfinden kann. Andererseits erlaubt dies die nahtlose Integration in die vorhandene ESRI-Systeminfrastruktur auf Basis von GeoOffice der Stadt Potsdam, so dass die Datenhaltung und Fortführung mit bereits bekannten Bearbeitungsfunktionen und Werkzeugen erfolgen kann. Die Abbildung 1 stellt das umgesetzte Datenbankmodell dar. Mittelfristig ist eine Überführung in eine zentrale Geodatenhaltungskomponente der DMZ vorzusehen, die aber vom Aufbau eines zentralen Geodatenservers im Zuge der Einrichtung einer Geodateninfrastruktur Potsdam (GDI.P) abhängig ist. 4

11 Abbildung 1: Datenbankmodell des Digitalen Gestaltplanes 1.3. Aktualisierungs- und Fortführungsworkflows Die Aktualisierung und Fortführung des Gestaltplanes ist grundsätzlich ein manueller Prozess, weil bei Veränderungen der Bestandsgebäude, wie auch bei der Neuerfassung, bzw. Nachführung von Planungen, Veränderungen der Flächenklassifikation vorzunehmen sind, die einer planerisch-inhaltlichen Abwägung bedürfen. Grundsätzlich sind drei Workflows zu unterscheiden: Aktualisierung der Klasse Bestandsgebäude (Objektklasse Bestand), Erweiterung des Gestaltplanes und Neuerfassung/Fortführung von Planungen Aktualisierung Bestandsgebäude Abriss, Neubau von Gebäuden sowie Lagekorrekturen von alten Grundrissen durch Neueinmessungen führen zu einer kontinuierlichen Veränderung der in der Liegenschaftskarte erfassten Bestandsgebäude. Um eine Kongruenz des Gestaltplanes mit den Gebäudegrundrissen rissen des Katasters zu wahren, ist es deshalb notwendig in regelmäßigen Abständen eine Aktualisierung der im Gestaltplan abgebildeten Bestandsgebäude vorzunehmen. Als Grundlage kann dazu auf einen ALK-Differenzdatensatz (Grundlage: Datenerstabgabe vom ) zurückgegriffen werden. Da bei der Fortführung der ALK nicht nur bei Abriss eines Gebäudes, sondern auch bei neuer Einmessung oder Attributänderung zunächst ein Löschauftrag ausgelöst wird, ist zunächst die komplette Löschliste in den Gestaltplan einzuarbeiten, bevor die aktuellen Bestandsdaten durch Verschneidung in den Gestaltplan übernommen werden können. 1. Schritt: ALK Gebäude löschen Das Löschen von Bestandsgebäuden erfolgt durch Verschmelzen des vorhandenen Grundrisses mit einer angrenzenden Fläche. Es liegt im Ermessen des zuständigen Bearbeiters, welchem angrenzenden Flächentyp der Bestandsgrundriss zugeschlagen wird und ob ggf. eine weitere Flächenbearbeitung 5

12 erwünscht ist. Da der Gestaltplan in Teilen nicht die reale Situation zeigt, sondern eine geplante Flächennutzung, kann es auch vorkommen, dass zu löschende Gebäude gar nicht im Gestaltplan abgebildet sind. In diesem Fall entfällt das Löschen. Abbildung 2 zeigt die Selektion eines zu löschenden Grundrisses und das Ergebnis der Flächenverschmelzung. Je nach Typ der angrenzenden Fläche und Gestaltungsaussage kann es nötig sein ggf. auch weitere Flächen in der Nachbarschaft zu verschmelzen oder zu bearbeiten. So wäre es denkbar, auch die Zuwegung in diesem Fall als Grünfläche zu reklassifizieren, wenn an der betreffenden Stelle ein Rückbau vorliegt. Abbildung 2: Verschmelzen eines Grundrisses mit der Nachbarfläche Die Identifikation der zu löschenden Bestandsgebäude kann mit Hilfe der Löschliste erfolgen, die im Rahmen der Fortführung des 3D-Stadtmodells erstellt wird (vgl. 2.3). Dazu wird die Löschliste in eine Tabelle überführt und diese mit der Attributtabelle Gestaltplan verknüpft. Alle Objekte, denen ein Wert aus der Löschliste zugeordnet wird, sind zu löschen (verschmelzen). 2. Schritt: ALK Gebäude einfügen Nach dem Löschen, erfolgt in einem zweiten Schritt die Integration neuer ALK-Daten. Dabei ist zunächst sicherzustellen, dass keine unerwünschten Gebäude (Tiefgaragen) mit integriert werden. Es ist weiterhin zu prüfen, ob neu einzufügende Grundrisspolygone sich mit Planungen überschneiden. Ist dies der Fall, ist vom Bearbeiter festzulegen, ob das neue Bestandspolygon eine Planung ersetzt oder ob es sich um einen Konflikt zwischen ALK und Gestaltplan handelt, dessen Behandlung individuell vom Bearbeiter zu entscheiden ist. Die Übernahme einzufügender Gebäudepolygone kann durch Kopieren und Verschneiden erfolgen (pro Gebäude, ArcView) oder durch die Ausstanzen (Erase) und Anhängen (Append) Werkzeuge aus der ArcGIS Toolbox (für mehrere Gebäude, Arc Editor). Auf Basis der Differenzdatenanalyse von Frau Giering (ANHANG), die nach einem Viertel Jahr 718 zu löschende und 733 einzufügenden Objekten aufzeigte, wird eine vierteljährliche Aktualisierung der Bestandsgebäude empfohlen, weil der Bearbeitungsaufwand pro Aktualisierungsdurchgang dann überschaubar bleibt (geschätzte Bearbeitungszeit ca. 1 Tag). 6

13 Aktualisierung und Erweiterungen des Gestaltplanes Der Gestaltplan als planerisches Instrument erfordert eine gewisse Aktualität um die Akzeptanz des Instrumentes zu fördern. Das bedeutet, dass nicht nur die Bestandsgebäude kontinuierlich aktualisiert werden müssen, sondern auch die übrige Flächennutzung, wenn größere Veränderungen (bspw. Neubau Nuthestrasse) vorliegen, damit die Plandarstellung die Realität oder auch aktuelle stadtplanerische Fragestellungen widerspiegelt. Ebenso kann sich zukünftig die Notwendigkeit ergeben, den Geltungsbereich zu erweitern. Um den Flächenschluss und die Konsistenz des Datensatzes zu erhalten sind bei den dazu erforderlichen Bearbeitungsoperationen folgende Regeln/Einstellungen zu beachten: 1. Grundeinstellungen für die Bearbeitung Um ein versehentliches Verrutschen von Features zu vermeiden, sollte die Sticky Moving Tolerance unter Editor->Optionen->Allgemein auf den Wert 25 oder größer eingestellt werden. Die Snapping-Tolerance sollte auf einen Wert zwischen 5-10 Pixel gesetzt werden. Alle Bearbeitungsoperationen sollten im Maßstab zwischen 1:250 (kleinteilige Features, Kurven) und 1:1000 (große Features) erfolgen. Um die Erfassung von Attributen während der Bearbeitung zu erleichtern, können unter Editor -> Optionen die Layer definiert werden, bei denen automatisch eine Attributabfrage bei der Editierung erfolgen soll: 7

14 2. Erweiterung des Geltungsbereichs Bei einer Erweiterung des Geltungsbereichs sollte grundsätzlich mit der Auto-Complete-Polygon gearbeitet werden, um den Flächenschluss zu gewährleisten. Es ist weiterhin darauf zu achten, dass das Snapping für den zu bearbeitenden Layer (Gestaltplan) aktiviert wird und dass der Layer als Ziellayer der Bearbeitung definiert ist. Die Erfassung neuer Features erfolgt, indem man auf einen Eckpunkt (oder Segment) eines bestehenden Features klickt, den Polygonzug für das zu erfassende Feature abklickt und schließlich die Erfassung durch einen Doppelklick auf ein bestehenden Knotenpunkt (oder Segment) abschließt. Die Schritte sind in der folgenden Abbildung dargestellt. Abbildung 3: In Gelb ist die Erweiterung einer Straßenfläche dargestellt. Das Attributeingabefenster öffnet sich nach Abschluss der Flächenerfassung automatisch (vgl. Grundeinstellungen für die Bearbeitung). 8

15 Ist die Option zur Erfassung von Attributen vor Speicherung eines neuen Features aktiviert (vgl. Punkt 1), so öffnet sich das Attributfenster nach Abschluss des Polygonzuges automatisch, so dass der/die Bearbeiter/in direkt den Objekttyp Type oder die Objektklasse CLASS_ID eingeben kann. Bestandsgebäude im Erweiterungsbereich sollten aus der ALK entnommen und per Copy & Paste oder per Anfügen-Operation (Append) hinzugefügt werden. Da das Attribut OBJEKTNAME in der ALK und im Gestaltplan angelegt ist, werden die Attributwerte dabei direkt aus der ALK in den Gestaltplan übernommen. Es wird empfohlen, nach Abschluss größerer Bearbeitungsoperationen durch Abfragen, bzw. durch Verknüpfung von Tabellen sicherzustellen, dass alle Attribute sachgerecht ausgefüllt sind. Für die Flächen, die den Bestand repräsentieren bedeutet dies, zunächst zu prüfen, ob der Objekttyp Type und die Objektklasse CLASS_ID beide konsistent ausgefüllt sind. Ist während der Bearbeitung nur eines der beiden Attribute erfasst worden, kann auf Basis des erfassten Attributes eine Tabellenverknüpfung (Join) zwischen der Attributtabelle des Gestaltplanes und der Objektklassentabelle erstellt werden (vgl. Abbildung 1). Fehlende Attributwerte können dann aus der Objektklassentabelle übernommen werden. Außerdem sollte per Abfrage geprüft werden, ob alle übernommenen Bestandsgebäude einen Attributwert OBJEKTNAMEN haben. Zuletzt sollte noch geprüft werden, ob alle Flächen, die den Bestand repräsentieren, den Attributwert 0 für das Attribut PA_ID haben. 3. Aktualisierung des Gestaltplanes Eine Aktualisierung ist bei Neubau von Straßen, Umwidmung von Flächen und ähnlichen größeren Änderungen der Flächennutzung erforderlich, die für eine planerisch-gestalterische Aussage oder für den Wiedererkennungswert des Betrachters relevant sind. Hierzu zählen insbesondere auch Aktualisierungen der Bestandsgebäude, die bereits beschrieben wurden und regelmäßig erfolgen sollten (vgl. Aktualisierung Bestandsgebäude). Im Gegensatz zu den Veränderungen der Bestandsgebäude, die aus der ALK abzuleiten sind, sind andere Flächenänderungen nur auf Basis von anderen Datenquellen, insbesondere aktuellen Luftbildern oder Vermessungsdaten, erfassbar. Bei der Einarbeitung solcher Veränderungen sollten ebenfalls die genannten Grundeinstellungen (Snapping, Sticky-Moving Toleranz) vor der Bearbeitung aktiviert werden. Die eigentliche Bearbeitung sollte dann mit Hilfe der Zerschneiden Funktion (Cut-Polygon), Zusammenfassen von Flächen (Merge Funktion), durch Umwidmung der Objekttypen (TYPE bzw. CLASS_ID) oder durch Löschen und Neuerfassung erfolgen. Bei der Neuerfassung sollte grundsätzlich wie oben beschrieben mit der Auto-Complete-Polygon Funktion gearbeitet werden, um den Flächenschluss sicherzustellen. 4. Thematische Erweiterungen Grundsätzlich ist der Gestaltplan auch thematisch erweiterbar. So könnten bspw. Schienen oder Konturlinien als weitere Objektklassen definiert werden, um eine detailliertere graphische Ausgestaltung zu erreichen. Bei einer Erweiterung sollte zunächst grundsätzlich die Objektklassentabelle (vgl. Tabelle 1) in der ESRI File-Geodatabase erweitert werden. In einem zweiten Schritt ist festzulegen, welche Attribute und welchen Geometrietyp die neue Objektklasse bekommen soll. Dann sind ggf. vorhandenen Daten 9

16 entsprechend dieser Definition aufzubereiten und in die Datenbank zu integrieren. Sind noch keine Daten verfügbar, kann der neue Objekttyp in der Datenbank definiert und die Objekterfassung mit den verfügbaren Editierwerkzeugen von ArcGIS durchgeführt werden Erfassung und Aktualisierung von Planungen Für die Erfassung und Aktualisierung von Planungen gelten grundsätzlich die gleichen Grundeinstellungen und Bearbeitungsregeln wie für die Aktualisierung und Erweiterung des Gestaltplanes. Das bedeutet, dass die Sticky-Moving Tolerance, Snapping-Tolerance, Bearbeitungsziel und Snapping-Einstellungen (s.o.) grundsätzlich einzustellen sind und nach Möglichkeit mit den Cut-, Merge- und Auto-Complete-Polygon Funktionen gearbeitet wird, um den Flächenschluss zu erhalten. 1. Aktualisierung Die Aktualisierung vorhandener Planungen sollte grundsätzlich mit den gleichen Werkzeugen und Einstellungen wie die Erfassung und Aktualisierung der Bestandssituation erfolgen. Dabei ist insbesondere darauf zu achten, dass alle neu erfassten oder bearbeiteten Objekte den passenden Attributwert für das Attribut PA_ID erhalten, damit eine Zuordnung einer Planung zu den Plangebieten und damit zu weiterführenden Planungsinformationen gegeben ist. Außerdem wird über die Plangebiets ID durch Verschmelzen (Dissolve-Funktion) aller Flächenobjekte in einem Plangebiet ein Gebietspolygon abgeleitet, dass zur sauberen Integration der Planung in den Gesamtdatenbestand benötigt wird (vgl. dazu auch Punkt 2. Erfassen von Planungen). 2. Erfassung von Planungen Die Erfassung von weiteren Planungen lässt sich in drei Phasen untergliedern, die sich in weitere Einzelschritte unterteilen lassen. Das folgende Ablaufdiagram zeigt die einzelnen Schritte, die nachfolgend erläutert werden. Abbildung 4: Ablaufdiagramm Erfassung von Planungen 10

17 1. Vorbereitende Arbeitsschritte Um neue Planungen nahtlos in den Gesamtplan integrieren zu können, sollte die Plangebietsabgrenzung möglichst mit bestehenden Flächengrenzen identisch sein, so dass möglichst wenige Bestandsflächen zerschnitten werden müssen. Um dies zu erreichen, wird zunächst in einem ersten Schritt das zu bearbeitende Gebiet großzügig selektiert und als temporärer Datensatz exportiert. Alle nachfolgenden Operationen werden ausschließlich auf diesem temporären Datensatz durchgeführt. Als zweiter Schritt wird das eigentliche Plangebiet definiert. Dazu werden Einzelflächen außerhalb des Plangebietes gelöscht und Flächen, die nur teilweise im Plangebiet liegen zerschnitten. Dabei sollte durch den/die Bearbeiter/in sichergestellt werden, dass nach Möglichkeit wenige Flächen zerschnitten werden. In der Regel lässt sich die Zerschneidung auf ein paar wenige Straßen, Gewässer und Grünflächen beschränken. Im Beispiel in Abbildung 5 sieht man, dass sich die zusätzliche Flächenzerschneidung auf einen Schnitt durch das Gewässer beschränken lässt und die restliche Abgrenzung entlang bestehender Flächengrenzen erfolgen kann. Abbildung 5: Beispielhafte Abgrenzung eines Planungsraumes 11

18 Ist die Abgrenzung erfolgt, kann die eigentliche Bearbeitung der Planung erfolgen. Zugleich kann man das so abgegrenzte Plangebiet mit der Bestandsdarstellung als Vorlage für externe Planungsbüros nutzen, um zukünftige Planungen effizienter zu erfassen und leichter integrieren zu können. In diesem Fall ist festzulegen, dass die Planung auf exakt den vorgelegten Ausschnitt zu begrenzen ist und die Plandarstellung sich auf die zuvor beschriebenen Objektklassen und Attributwerte beschränken soll. 2. Bearbeitung In der zweiten Phase erfolgt die eigentliche Bearbeitung, die durch Löschen, Einfügen, Zerschneiden und Zusammenfassen von Flächen sowie die Zuweisung der Attributinformationen zu den Flächen erfolgt. Dazu stehen die bereits genannten Bearbeitungswerkzeuge von ArcGIS zur Verfügung und es sollten dieselben Grundeinstellungen und Semantikprüfungen vorgenommen werden (vgl. Aktualisierung und Erweiterungen des Gestaltplanes). Die Bearbeitung wurde bereits anhand eines Beispielgebietes exemplarisch gezeigt und nachfolgend durch Frau Kelch übernommen, so dass der Prozess grundsätzlich bekannt und etabliert ist. 3. Integration und Dokumentation Im dritten Schritt erfolgt die Integration des fertig bearbeiteten Plangebietes in den Gestaltplan und die Dokumentation. Dazu wird zunächst das bearbeitete Plangebiet zunächst auf Basis des Attributes PA_ID aufgelöst, so dass ein Umringpolygon des Gebietes entsteht. Dies wird als Stanzform zum Ausschneiden des Gebietes aus dem Gestaltplan verwendet und in einem weiteren Schritt wird das Plangebiet in den Plan eingefügt. Bei kleineren Gebieten kann das mit Hilfe der Copy & Paste Funktion erfolgen, bei größeren Gebieten wird die Nutzung der Append- Funktion (Anhängen) aus der Arc-Toolbox empfohlen. Abbildung 6: Integration eines Plangebietes durch Bildung des Flächenumringes, Ausstanzen des Plangebietes und Integration der Planung Abschließend wird noch der Gebietsumring in die Tabelle Plangebiete integriert (per Copy&Paste und Clip-Funktion). Diese dient zur Erfassung und Beschreibung der Plangebiete. Dort können 12

19 der Plangebietsname, Bearbeiterinformationen, Bearbeitungszeitpunkte und Relationen zu weiteren Plänen dokumentiert werden Topologie und Semantikprüfung Zum Abschluss größerer Bearbeitungsoperationen oder nach mehreren Kleinen sollten Topologieprüfungen und Semantikprüfungen durchgeführt werden. Eine Topologie des Gestaltplanes ist in der Geodatenbank angelegt. Um diese zu validieren und zu bearbeiten wird eine ArcEditor Lizenz benötigt, die in der Stadtverwaltung vorhanden ist. Folgende Topologieregeln sind definiert: Must Not Have Gaps (keine Löcher) Must Not Overlap (keine Überlappung) Um Topologiefehler zu Bearbeiten müssen die Topologie und die damit verbundenen Daten in ArcMap geladen und eine Edit-Session gestartet werden. Zur Bearbeitung stehen spezielle Topologietools zur Verfügung um Gaps zu schließen oder Overlaps zu mergen. Neben der Topologieprüfung sind auch Semantikprüfungen regelmäßig durchzuführen, um die Konsistenz des Datensatzes zu erhalten. Dazu sollte über Abfragen sichergestellt werden, dass die Belegung der Werte für die Attribute TYPE und CLASS_ID konsistent sind, dass alle Plangebäude mit einer Höhe und einer Stockwerksangabe verbunden sind, dass alle Bestandsgebäude einen Wert für das Attribut OBJEKTNAME aufweisen und dass zu jedem Bestandsgebäude ein Eintrag in der Tabelle ALK- Attribute vorliegt Integration als WMS/WFS-Dienste in die Potsdamer GDI Die vorgesehene Integration des Gestaltplanes in die Potsdamer Geodateninfrastruktur (GDI) konnte im Rahmen des Vorhabens nicht realisiert werden, weil zum aktuellen Zeitpunkt die GDI Potsdam nicht realisiert ist. Alternativ, um den EFRE-Vorgaben zu entsprechen, wird der Potsdamer Gestaltplan als Web Mapping Anwendung und als öffentlicher WMS-/WFS-Dienst durch die virtualcitysystems GmbH im Rahmen eines Wartungsvertrages bereitgestellt, bis eine Integration in die GDI Potsdam möglich wird. Im Wartungsvertrag ist ein monatliches Update enthalten. Zur Durchführung eines Datenupdates steht der Stadt Potsdam ein Uploadverzeichnis auf dem Hostingserver zur Verfügung, in das die aktualisierten Daten als Shapefile abgelegt werden. Nach erfolgreichen Upload der Daten ist eine Benachrichtigung an zu senden und dann werden die aktualisierten Daten innerhalb eines Werktages freigeschaltet. Parallel zur Bereitstellung des Digitalen Gestaltplanes Potsdam als OGC-Dienst wird auch eine Webmappinganwendung auf Basis der Open Source Software MapGuide Open Source bereitgestellt, die in vorhandene Internetseiten der Stadt Potsdam integriert oder als eigenständige Internetanwendung von der Stadt genutzt werden kann. Diese Anwendung ist unter erreichbar. Aktuell ist die Anwendung noch mit einem Kennwortschutz versehen, der nach Prüfung der 13

20 Validität der Daten und Entwicklung einer Veröffentlichungsstrategie durch die Stadt abgeschaltet werden kann. Anbei die Auflistung der OGC-Dienste: Web Map Service: GetCapabilities ORMAT=text/xml GetCapabilities ORMAT=text/xml GetMap Gestaltplan estaltplan&srs=epsg:25833&bbox=367000, ,368400, &width=600&h EIGHT=400&FORMAT=image/png Umring Baumbestand GetFeatureInfo Gestaltplan DescribeLayer Gestaltplan Web Feature Service mring&srs=epsg:25833&bbox=360000, ,374000, &width=600&heigh T=600&FORMAT=image/png aumbestand&srs=epsg:25833&bbox=360000, ,374000, &width=600 &HEIGHT=600&FORMAT=image/png ERS=gestaltplan&QUERY_LAYERS=gestaltplan&FEATURE_COUNT=50&x=500&y=400&SR S=EPSG:25833&bbox= , , , &WIDTH=600&HE IGHT=400&FORMAT=image/png RS=gestaltplan&outputFormat=application/json GetCapabilities RMAT=text/xml GetCapabilities RMAT=text/xml GetCapabilities RMAT=text/xml Unterstützte EPSG:25832, EPSG:25833, EPSG:325833, EPSG:4258, EPSG:4326, EPSG:4839, CRS:84 Koordinatensysteme: 14

21 2. LoD1 Stadtmodell Potsdam Ziel des Teilvorhabens LoD1 3D-Stadtmodell war die Überführung von Daten aus dem Liegenschaftskataster nach VALK-Richtlinie in ein LoD1-Gebäudemodell der Stadt mit dem Ziel aus den enthaltenen 3D-Informationen (FOKHO, TRAUH) ein 3D-Gebäudemodell zu erzeugen. Zentrale Anforderungen sind die Modellierung des Gebäudemodells im OGC Standard CityGML, die Schaffung von Integrationsschnittstellen für bereits vorhandene 3D-Gebäudemodelle, die Einrichtung von Transformationsfunktionen zur Bereitstellung der Daten in unterschiedlichen Projektionen, die Entwicklung von Funktionen zum Export im OGC-konformen KML/Collada Format, die Konzeption einer Veröffentlichungslösung auf Basis von Google Earth und die Definition eines Fortführungsworkflows Datenmodell Als Datenmodell wird der internationale OGC-Standard CityGML eingesetzt. Dieses Datenmodell wurde speziell für die Speicherung und den Austausch von 3D-Stadtmodellen entwickelt. CityGML hat sich seit der Anerkennung als OGC-Standard im Jahr 2008 zunehmend etabliert und bildet auch die Grundlage für die Empfehlung der AdV zur Modellierung und Speicherung von 3D-Gebäudedaten im Rahmen von ALKIS3D. Damit wird ein offenes, standardisiertes und zukunftsweisendes Geodatenmodell eingesetzt. Auf eine ausführliche Darstellung des Datenmodells wird an dieser Stelle verzichtet und auf die CityGML- Spezifikation des OGC verwiesen. Die Dokumentation liegt dem mitgelieferten Datenträger bei und kann unter heruntergeladen werden. Weitere Informationsquellen zum Thema CityGML, zu verfügbaren Softwaretools und aktuellen Entwicklungen finden sich auf dem CityGML Wiki unter sowie auf der CityGML Homepage Datenhaltung Die Datenhaltung erfolgt auf dem Oraclecluster der Landeshauptstadt Potsdam. Dazu wurde eine Datenbankinstanz angelegt und Vorort das von der TU Berlin als Open Source Projekt entwickelte CityGML-konforme Datenbankschema 3D City Database eingespielt. Als Datenbankfrontend kann einerseits die in der Stadtverwaltung verfügbare Software LandXplorer Studio Professional verwendet werden, die sich insbesondere zur Visualisierung der Daten und zur Erstellung und Verwaltung von Planungsvarianten eignet. Andererseits kann der 3D City Database Importer/Exporter verwendet werden, der sich insbesondere für die Einspielung von Daten sowie für die Ausspielung im CityGML und KML/Collada-Format eignet. Letztere Funktion des Importer/Exporters wurde im Rahmen des Vorhabens entwickelt um eine öffentliche Bereitstellung der Daten auf Basis des OGC-Standards KML in Google Earth zu ermöglichen. Durch die Unterstützung eins KML/Collada-Exports können die Stadtmodelldaten in Google Earth veröffentlicht werden. Zugleich ist KML/Collada ein weit verbreitetes Format zur 3D- Modellierung, was eine Nachnutzung der 3D-Daten durch Architekten und Ingenieure erleichtert. Die KML/Collada Exportfunktionen und ein Workflow zur Veröffentlichung der Stadtmodelldaten in Google Earth werden im Abschnitt gesondert betrachtet. 15

22 2.3. Fortführungskonzept Ein zentrales Anliegen des Vorhabens war es ein Fortführungskonzept für den LoD1-Gebäudebestand zu entwickeln, damit das Stadtmodell eine Katasteraktualität aufweist. In Abstimmung mit der Vermessungsverwaltung der Stadt Potsdam wurden dazu die Anforderungen analysiert und als Ergebnis der in Abbildung 7 dargestellte Fortführungsworkflow definiert. Die einzelnen Prozessschritte im Detail: 1. Ausspielung der Differenzdaten aus der Katasterdatenbank und Datenaufbereitung Im ersten Schritt müssen die Differenzdaten zur letzten Ausspielung ausgegeben und anschließend aufbereitet werden. Die Aufbereitung erfolgt skriptbasiert und liefert im Ergebnis zwei Datensätze. Der eine Datensatz ist eine Löschliste (ALK Löschliste), die eine kommaseparierte Liste des Attributwerts OBJEKTNAME aller gelöschten Grundrisse (Katasterobjekte) enthalten muss. Der zweite Datensatz ist ein Shapefile (ALK Neu) nach VALK Richtlinie mit den Grundrissen der neu eingefügten (bzw. geänderten) Gebäude. Die Attributtabelle des Shapefiles wird um Daten zur Anzahl der Geschoße aus dem Klimaschutzkonzept ergänzt. Das Ergebnis Shapefile muss am Ende der Aufbereitung die in Tabelle 5 gelisteten Attribute enthalten. Beiden Datensätze zusammen bilden die Grundlage für die Fortführung des 3D-Stadtmodells. Die Verantwortlichkeit und die Prozesse für die Datenausspielung und -Aufbereitung liegen beim FB42. Der Prozess ist nach Möglichkeit weitgehend zu automatisieren. Entsprechende Anpassungen des Workflows und der Skripte werden bereits untersucht. Die erforderlichen Softwaretools sind im FB42 vorhanden. Tabelle 5: Erwartete Attributwerte nach Datenaufbereitung (entspricht Datenabgabe vom ) Attributname Inhalt Datentyp FID Feature ID (ArcGIS) Integer Shape Geometrietyp (Polygon) Polygon OBJECTID Weitere ObjektID Integer OBJEKTNAME Kodierte Objektadresse String OS Objektschlüssel String OSBEZ Objektschlüssel Klartext String FOLIE ALK Foliennummer (11 84) Integer FOLIENBEZ ALK Foliennummer Klartext String DFIHO Dachfirsthöhe in mm Integer DFIHW Dachfirst Hochwert in mm Integer DFIRW Dachfirst Rechtswert in mm Integer DFORM Dachform Integer FOKHO Fußbodenoberkante in mm Integer FOKHW Fußbodenoberkante Hochwert in mm Integer FOKRW Fußbodenoberkante Rechtswert in mm Integer TRAUH Traufhöhe in mm Integer GESCHOSS Anzahl der Geschosse (aus Klimakonzept) Double GebH Gebäudehöhe (aus Klimakonzept) Double 16

23 Abbildung 7: Fortführungsworkflow LoD1-Stadtmodell und Konzept LoD2 Fortführung 17

24 2. Löschen der Gebäudeobjekte aus der 3D City Database Das Löschen von Gebäudeobjekten aus der Datenbank erfolgt mit Hilfe des SQL-Skriptes DELETE_BUILDING_BY_ID_VERSIONED.sql. Das Skript wird im SQL-Developer gestartet und erwartet die Eingabe von kommaseparierten Werten des Attributes OBJEKTNAME. Nach Eingabe der Werte (Copy & Paste aus der Löschliste) werden die entsprechenden Stadtmodellobjekte (Gebäude) aus der Datenbank gelöscht. Die Verantwortlichkeit für das Löschen der Objekte liegt im FB42. Das Löschskript wird mit dieser Dokumentation auf einem Datenträger ausgeliefert, der SQL- Developer ist in der Stadtverwaltung vorhanden. Eine Einführung vor Ort kann bei Bedarf erfolgen und sollte unter Einbeziehung der DB-Administratoren (Fr. Felsner, Fr. Schob) stattfinden. 3. Filterung, Prüfung und Ergänzung der einzufügenden Gebäude Im dritten Prozessschritt müssen die neuen ALK Daten gefiltert, geprüft und ergänzt werden. Zunächst werden Tiefgaragen und ggf. andere unterirdische Bauwerke aus den neuen ALK-Daten entfernt. Dann erfolgt eine Prüfung auf Vollständigkeit der für die Modellbildung erforderlichen Höhenattribute FOKHO und TRAUH. Objekte die diese Höheninformation nicht enthalten, müssen in einem weiteren Arbeitsschritt qualifiziert werden, indem die Höheninformationen nacherfasst werden. Zur Prüfung auf Vollständigkeit der Höheninformationen wurde im Vorhaben eine ArcGIS Toolbox (Abbildung 8) angelegt, die über Selektionen eine Filterung der Daten ermöglicht. Diese wird mit dieser Dokumentation bereitgestellt. Die Toolbox erwartet die Eingabe der in Prozessschritt 1 aufbereiteten ALK Daten mit den in Tabelle 5 gelisteten Attributen. Diese werden nach den in Tabelle 6 aufgeführten Bedingungen gefiltert. Tabelle 6 zeigt auch die Ergebnisse der der Prüfung im Vorhaben und die auf die Ergebnisdaten anzuwendenden Folgeprozesse. Im Vorhaben beschränkte sich die Nacherfassung von Höhendaten auf die Gebäude, zu denen Geschoßangaben aus dem Klimaschutzkonzept Potsdam vorlagen oder zu denen die Traufhöhe aber keine Fußbodenhöhe vorhanden war. Dazu wurden die niedrigsten Höhenwerte des Potsdamer Geländemodells innerhalb der Grundrisse ermittelt und als FOKHO definiert. Dann wird die TRAUH nach der Formel TRAUH = FOKHO + (Geschosszahl * 3) berechnet. Den Attributtabellen wird eine Spalte HSOURCE angefügt und allen Grundrissen, die Höhenwerte aus der photogrammetrischen Messung aufweisen, wird der Attributwert 1 zugewiesen, den Grundrissen, die auf Basis der Anzahl der Geschoße modelliert werden, erhalten den Wert 2. So wird sichergestellt, dass die Qualität der Höhenangabe nachvollziehbar dokumentiert ist. Für Daten, die sowohl eine FOKHO als auch eine TRAUH-Angabe enthalten, erfolgt dies bei Nutzung der ArcGIS-Toolbox automatisch. 18

25 Tabelle 6: Prüf- und Filterbedingungen Bedingung Ergebnisshapefile Anz. Gebäude Folgeprozess OSBEZ = Tiefgaragen, unterirdische 44 entfällt 'Tiefgarage' OR Gebäude OSBEZ = 'unterirdische Gebäude' FOKHO > 0 AND Hoeheninformation_VALK Daten sind bereit für Konvertierung TRAUH > 0 FOKHO = 0 AND Hoeheninformation_nur_TRAUH 36 FOKHO aus DGM ableiten TRAUH > 0 FOKHO = 0 AND Hoeheninformation_aus_AnzG 2427 FOKHO aus DGM ableiten und TRAUH TRAUH = 0 AND Geschoss > 0 berechnen: TRAUH = FOKHO + (Geschosszahl* 3) Summe: FOKHO > 0 AND TRAUH = 0 FOKHO < 0 OR TRAUH < 0 FOKHO = 0 AND TRAUH = 0 AND Geschoss = 0 Hoeheninformation_nur_FOKHO Negative_TRAUH_oder_FOKHO Keine_Hoeheninformation 17 z.z. nicht integriert, Prozess zur Erfassung der Höheninformation muss definiert werden 1 z.z. nicht integriert, Prozess zur Erfassung der Höheninformation muss definiert werden 6118 z.z. nicht integriert, Prozess zur Erfassung der Höheninformation muss definiert werden Für die im Vorhaben nicht modellierten Gebäude ohne Höheninformationen ist der Schritt der Attributergänzung zukünftig durch Einbeziehung weiterer Datenquellen vorzunehmen. Eine geeignete Datenquelle für die Ergänzung könnten die Bauakten oder terrestrische Messungen sein. Vor diesem Hintergrund wird empfohlen, dass innerhalb der Verwaltung geprüft wird, wie zukünftig eine effiziente und möglichst konsistente Erfassung der Höhenwerte erfolgen soll. Die Verantwortung für die Aufbereitung der Daten liegt im FB42. Die Datenfilterung und Prüfung kann mit der bereitgestellten ArcGIS-Toolbox erfolgen. Für die Ermittlung fehlender FOKHO-Werte aus dem DGM wurde eine FME-Workbench entwickelt, die durch den Auftragnehmer bereitgestellt wird. Ergänzung: Zurzeit ist noch unklar, woher die benötigten Höheninformationen für die bisher nicht beachteten Gebäude kommen sollen. Dies ist in der Vermessungsverwaltung zu diskutieren und entsprechende Workflows sind in der Verwaltung vorzusehen. Als mögliche Datenquellen für die Höheninformationen kommen terrestrische Vermessungen oder Bauakten in Betracht. Angesichts der bevorstehenden Erfassung eines LoD2 Gebäudemodells durch die Stadt Potsdam, wird empfohlen zunächst die Ergebnisse der LoD2-Modellierung abzuwarten, weil damit zugleich Höheninformationen für alle bisher nicht bearbeiteten Gebäude erfasst werden. Dann sollte in einem zweiten Schritt ein weitergehender Fortführungsworkflow erarbeitet werden (vgl. Abbildung 7), der zugleich die LoD2-Fortführung abdeckt. 19

26 Abbildung 8: ArcGIS Toolbox zur Datenprüfung und -Filterung 4. Konvertierung der neuen ALK-Daten in ein LoD1-Gebäudemodell Die Konvertierung der vorbereiteten Daten (Datensätze 1-4 aus Tabelle 6) in LoD1 Gebäudemodelle erfolgt mit der im Vorhaben entwickelten Konvertersoftware shape2citygml und der ebenfalls vorbereiteten Konfigurationsdatei Potsdam_lod1.shp2gml sowie einer aktuellen Adressdatenliste im CSV-Format. Für eine fehlerfreie Konvertierung ist es unerlässlich, dass die Attributbelegung und Benennung exakt den Vorgaben aus Tabelle 5 entspricht. Zunächst werden die zu konvertierenden Grundrisse im Shapefileformat geladen und ein Speicherort für die erzeugten CityGML-Daten angegeben. 20

27 Abbildung 9: Benutzeroberfläche shape2citygml-konverter Schritt 1 Als nächstes muss im Reiter Address zunächst die Vorlagedatei PotsdamAdressdaten.xml geladen werden (Erst Auswahl der Datei, dann den Button Read Template klicken). Damit ein Mapping der Adressdaten auf Basis des Attributwertes OBJEKTNAME erfolgen kann, ist zusätzlich eine CSV-Datei mit den Adressdaten anzugeben. Diese wurde aus der bestehenden Excelliste durch Speichern als CSV erstellt. Es ist wichtig, dass diese Adressmappingdatei bei Änderungen aktualisiert wird, damit die Adresszuordnung korrekt bleibt. Abbildung 10: Benutzeroberfläche shape2citygml-konverter Schritt 2 21

28 Nach Konfiguration der Anwendung wird mit dem Button Convert die Datentransformation gestartet. Als Ergebnis wird eine CityGML-Datei mit den LoD1-Gebäuden in das angegebene Verzeichnis geschrieben. Die Verantwortung für den Konvertierungsprozess liegt im FB42. Zu beachten ist die richtige Attributbelegung nach Tabelle 5. Die Software und Konfigurationsdateien zur Konvertierung der Daten wurden im Vorhaben entwickelt und als ausführbares Programm und als Quellcode sowie einer umfassenden Dokumentation bereitgestellt. 5. Import der vorbereiteten LoD1-Gebäude in die 3D City Database Der Import erfolgt mit dem Open Source Importer/Exporter für die 3D City Database, der im Rahmen des Vorhabens erweitert wurde und mit dieser Dokumentation ausgeliefert wird, bzw. bereits am Arbeitsplatz von Frau Felsner und Frau Kelch eingerichtet ist. Im Rahmen des Vorhabens erfolgte eine Einspielung der in Tabelle 6 gelisteten Gebäude im LoD1 Vorort. Bei der Fortführung sind dann nur noch die neuen ALK-Gebäude zu ergänzen. Damit die eine Nachvollziehbarkeit der Datenherkunft, bzw. des Erfassungsdatums gegeben ist, sollte bei jedem Fortführungsfall eine Datenherkunft (Lineage) angegeben werden. Es wird empfohlen diesen Wert nach dem Muster ALK_Fortführung_JJJJMMDD zu benennen. Ein beispielhafter Importworkflow wird im Folgenden dokumentiert. Zum Import wird der Importer/Exporter gestartet. Es erscheint der folgende Startbildschirm: 22

29 Zunächst ist eine Verbindung zur Datenbank herzustellen. Dies erfolgt im Reiter Datenbank. Geben Sie hier die Verbindungsdaten ein. Nachdem eine Datenbankverbindung aufgebaut wurde, sind die Importoptionen im Reiter Voreinstellungen zu konfigurieren. Geben Sie hier eine Beschreibung der Datenabstammung (Lineage) und den Aktualisierungsgrund (ALK Fortführung) ein. Es wird empfohlen, als Lineage das folgende Format zu verwenden: ALK_JJJJMMTT, damit nachvollziehbar ist woher die Daten zu welchem Datum stammen. Die weiteren Importoptionen brauchen nicht angepasst werden, weil die Standardeinstellungen ausreichen. Wechseln Sie in den Reiter Import und geben Sie den Pfad zu den zu importierenden Datei(en) an. Achten Sie darauf, dass Bei Workspace Live eingetragen ist, damit die Daten in den Livedatenbestand eingespielt werden. Da es sich nur um die ALK Gebäude handelt und diese komplett einzuladen sind, müssen keine Filter definiert werden und Sie können den Importprozess starten. Die Daten werden jetzt in die Datenbank geschrieben. 23

30 Nach Abschluss des Exportprozesses wird eine Statusmeldung ausgegeben. Dieser können Sie entnehmen, ob alle Objekte importiert wurden. Der Importprozess ist damit abgeschlossen. Die Verantwortung für den Import der Fortführungsdaten liegt beim FB 42. Die erforderlichen Softwarekomponenten werden bereitgestellt und sind als Open Source Software unter öffentlich verfügbar Export und Visualisierung des 3D-Stadtmodells Ein wesentliches Ziel des Vorhabens war es, Funktionen und Schnittstellen zur Datenabgabe des Stadtmodells in unterschiedlichen Koordinatensystemen und zur Visualisierung in Google Earth zu entwickeln, damit eine verwaltungsweite und/oder öffentliche Bereitstellung erfolgen kann. Daneben bietet das in der Verwaltung eingesetzte Softwarepaket Autodesk LandXplorer Studio eine direkte Schnittstelle zur Datenbank, die die Erzeugung von hochwertigen Vieweranwendungen ermöglicht. Eine Kurzanweisung in das Arbeiten mit der Datenbankschnittstelle wurde Vorort vorgenommen, eine ausführliche Schulung war jedoch nicht Bestandteil des Vorhabens. Die Dokumentation beschränkt sich deshalb auf eine Beschreibung des Workflows zur Visualisierung in Google Earth und zum Export von Daten im CityGML und KML/Collada-Format KML/Collada Export und Visualisierung in Google Earth Grundlage der Visualisierung des Potsdamer Stadtmodells in Google Earth ist eine im Vorhaben entwickelte KML/Collada-Exportfunktion, die in den Importer/Exporter integriert wurde. Diese erlaubt es, in der Datenbank gespeicherte Gebäudemodelle in das KML/Collada-Format zu konvertieren, die dann in Google Earth eingebunden werden können. Umfangreiche Optionen zur Konfiguration der Darstellung, zur Kachelung der Daten sowie zur Darstellung von Attributwerten ermöglichen eine optimale Aufbereitung, so dass auch sehr umfangreiche Datenmengen in Google Earth eingebunden werden können. Darüber hinaus wurde eine Funktion implementiert, um die Geländehöhe des Google 24