PDF Dokument anzeigen - Digitaler Gestaltplan Potsdam
Werbung
Projektdokumentation Digitaler Gestaltplan Potsdam Das Vorhaben Digitaler Gestaltplan Potsdam wurde aus Mitteln des Europäischen Fonds für Regionale Entwicklung gefördert. Bearbeitung: Dr.-Ing. Lutz Ross virtualcitySYSTEMS GmbH Cicerostr. 21 10709 Berlin Stefanie Buchta Landeshauptstadt Potsdam Hegelallee 6-10, Haus 7 14469 Potsdam Ansprechpartner: Erik Wolfram Landeshauptstadt Potsdam Hegelallee 6-10, Haus 1 14469 Potsdam Inhaltsverzeichnis Abbildungsverzeichnis ............................................................................................................................. II Tabellenverzeichnis ................................................................................................................................. II Einleitung ................................................................................................................................................ 1 1. Digitaler Gestaltplan Potsdam .......................................................................................................... 1 1.1. 2. Datenmodell............................................................................................................................. 1 1.1.1. Flächenobjekte ................................................................................................................. 2 1.1.2. Punktobjekte .................................................................................................................... 3 1.2. Datenhaltung und Datenbankmodell ........................................................................................ 4 1.3. Aktualisierungs- und Fortführungsworkflows ............................................................................ 5 1.3.1. Aktualisierung Bestandsgebäude ...................................................................................... 5 1.3.2. Aktualisierung und Erweiterungen des Gestaltplanes ........................................................ 7 1.3.3. Erfassung und Aktualisierung von Planungen .................................................................. 10 1.3.4. Topologie und Semantikprüfung ..................................................................................... 13 1.3.5. Integration als WMS/WFS-Dienste in die Potsdamer GDI ................................................ 13 LoD1 Stadtmodell Potsdam ............................................................................................................ 15 2.1. Datenmodell........................................................................................................................... 15 2.2. Datenhaltung ......................................................................................................................... 15 2.3. Fortführungskonzept .............................................................................................................. 16 2.4. Export und Visualisierung des 3D-Stadtmodells ...................................................................... 24 2.4.1. KML/Collada Export und Visualisierung in Google Earth .................................................. 24 2.4.2. Export im CityGML Format .............................................................................................. 27 3. Zusammenführung Gestaltplan und 3D-Stadtmodell ...................................................................... 30 4. Übersicht der Daten, Softwarekomponenten und Skripte............................................................... 32 I 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). ........................................................................................................................................... 8 Abbildung 4: Ablaufdiagramm Erfassung von Planungen ........................................................................ 10 Abbildung 5: Beispielhafte Abgrenzung eines Planungsraumes .............................................................. 11 Abbildung 6: Integration eines Plangebietes durch Bildung des Flächenumringes, Ausstanzen des Plangebietes und Integration der Planung.............................................................................................. 12 Abbildung 7: Fortführungsworkflow LoD1-Stadtmodell und Konzept LoD2 Fortführung ......................... 17 Abbildung 8: ArcGIS Toolbox zur Datenprüfung und -Filterung ............................................................... 20 Abbildung 9: Benutzeroberfläche shape2citygml-Konverter – Schritt 1 .................................................. 21 Abbildung 10: Benutzeroberfläche shape2citygml-Konverter – Schritt 2 ................................................ 21 Abbildung 11: Veröffentlichung in Google Earth..................................................................................... 25 Abbildung 12: Darstellungsoptionen für den KML/Collada-Export .......................................................... 26 Abbildung 13: Konfiguration von Balloons zur Ausgabe von Attributen in Google Earth ......................... 26 Abbildung 14: Exporteinstellungen der ausgelieferten Beispielausspielung ............................................ 27 Abbildung 15: Koorindatenreferenzsysteme einstellen .......................................................................... 28 Abbildung 16: Exportdialog des Importer/Exporters............................................................................... 29 Abbildung 17: Beispielhafte Integration von Plangebäuden, Planzeichnung und Plangebietsabgrenzungen in LandXplorer Studio Professional......................................................................................................... 31 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 11.3.2011) . 16 Tabelle 6: Prüf- und Filterbedingungen .................................................................................................. 19 II Digitaler Gestaltplan Stadtmodell Potsdam und LoD1- 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 LoD1Stadtmodells, 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 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. 1.1. 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 Tabelle 1: Objektklassen und Geometrietypen des digitalen Gestaltplanes Potsdam Objektklasse (Type) Geometrietyp CLASS_ID 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 1.1.1. 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 OBJECTID SHAPE OBJEKTNAME TYPE CLASS_ID PA_ID ANZ_VG GEB_HOEHE GS_ZUSATZ Shape_Length Shape_Area Beschreibung Fortlaufende Objekt ID, wird von ArcGIS verwaltet Geometrietyp Polygon, wird von ArcGIS verwaltet Gebäudekennzeichen nach VALK Richtlinie, wird für Bestandsgebäude vergeben Klarname des Flächentyps gemäß Tabelle 1 Klassen ID der Objektklasse Planungsgebiets ID zur Zuordnung der Plangebiete Anzahl der Vollgeschosse, gilt nur für geplante Gebäude (Gesicherte Planung und Langfristige Planung) Gebäudehöhe als Dezimalzahl, gilt nur für geplante Gebäude (Gesicherte Planung und Langfristige Planung) Zusatz zur Gebäudeausgestaltung Länge des Polygonzuges Fläche des Polygons Datentyp Integer String String String Integer Integer Integer Double String Double 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 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. 1.1.2. 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 Tabelle 4: Attributbezeichnung und Erläuterung zu den Baumstandorten Attributbezeichnung OBJECTID Shape PKTNR PKTX PKTY PKTZ GGARTBEZ CLASS_ID PA_ID QUELLE Beschreibung Fortlaufende Objekt ID, wird von ArcGIS verwaltet Geometrietyp Point, wird von ArcGIS verwaltet Aus der Stadtkarte übernommene Punktnummer Aus der Stadtkarte übernommener X-Wert Aus der Stadtkarte übernommener Y-Wert Aus der Stadtkarte übernommener Z-Wert Aus der Stadtkarte übernommene Klassifizierung in Laub- und Nadelbäume Klassen ID der Objektklasse gemäß Tabelle 1 Planungsgebiets ID zur Zuordnung der Plangebiete 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. 1.2. 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 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 sind,, die einer planerisch planerisch-inhaltlichen Abwägung bedürfen. Grundsätzlich sind drei Workflows zu unterscheiden: Aktualisierung der Klasse Bestandsgebäude gebäude (Objektklasse Bestand), Bestand), Erweiterung des Gestaltplanes und Neuerfassung/Fortführung von Planungen. 1.3.1. Aktualisierung Bestandsgebäude Abriss, Neubau von Gebäuden sowie Lagekorrekturen von alten Grundrissen durch Neueinmessungen Neu führen zu einer kontinuierlichen erlichen Veränderung der in der Liegenschaftskarte erfassten Bestandsgebäude. Um eine Kongruenz des Gestaltplanes mit den Gebäudegrundrissen Gebäudegrun 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 Differenzdatensatz (Grundlage: Datenerstabgabe vom 11.03.2011) zurückgegriffen werden. Da bei der Fortführung der ALK nicht nur bei Abriss eines Gebäudes, sondern auch bei neuer neue 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 lagen wird und ob ggf. eine weitere Flächenbearbeitung 5 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 1.3.2. 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 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 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 entsprechend dieser Definition aufzubereiten und in die Date Datenbank nbank 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. 1.3.3. Erfassung und Aktualisierung von Planungen Für die Erfassung ssung 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 Sticky-Moving Tolerance, Snapping-Tolerance, Tolerance, Bearbeitungsziel Bearbeitung und Snapping-Einstellungen (s.o.) grundsätzlich einzustellen sind und nach Möglichkeit mit den Cut-, Cut Merge- und Auto-Complete-Polygon Polygon Funktionen gearbeitet wird, um den Flächenschluss zu erhalten erhalten. 1. Aktualisierung Die Aktualisierung vorhandener Plan Planungen ungen 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 ert 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 (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 sic in drei Phasen hasen 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 Planun 10 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 Ist die Abgrenzung erfolgt, kann die 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 fügung und es sollten dieselben Grundeinstellungen und Semantikprüfungen vorgenommen werden (vgl. Aktualisierung und Erweiterungen des Gestaltplanes). Gestaltplanes Die Bearbeitung wurde bereits anhand eines Beispielgebietes exemplarisch gezeigt und nachfolgend nachfol 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 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 rd 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 AppendFunktion (Anhängen) aus der Arc-Toolbox Arc 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 der Plangebietsname, Bearbeiterinformationen, Bearbeitungszeitpunkte und Relationen zu weiteren Plänen dokumentiert werden. 1.3.4. 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 ALKAttribute vorliegt. 1.3.5. 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 lross@virtualcitysystems 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 www.digitaler-gestaltplan-potsdam.de erreichbar. Aktuell ist die Anwendung noch mit einem Kennwortschutz versehen, der nach Prüfung der 13 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 1.1.1 GetCapabilities 1.3.0 http://www.digitaler-gestaltplan-potsdam.de/ogcservices/potsdam/wms?REQUEST=GETCAPABILITIES&SERVICE=WMS&VERSION=1.1.1&F ORMAT=text/xml http://www.digitaler-gestaltplan-potsdam.de/ogcservices/potsdam/wms?REQUEST=GETCAPABILITIES&SERVICE=WMS&VERSION=1.3.0&F ORMAT=text/xml GetMap Gestaltplan http://www.digitaler-gestaltplan-potsdam.de/ogcservices/potsdam/wms?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&LAYERS=g estaltplan&SRS=EPSG:25833&BBOX=367000,5806800,368400,5807800&WIDTH=600&H EIGHT=400&FORMAT=image/png Umring http://www.digitaler-gestaltplan-potsdam.de/ogcservices/potsdam/wms?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&LAYERS=u mring&SRS=EPSG:25833&BBOX=360000,5800000,374000,5815000&WIDTH=600&HEIGH T=600&FORMAT=image/png http://www.digitaler-gestaltplan-potsdam.de/ogcservices/potsdam/wms?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&LAYERS=b aumbestand&SRS=EPSG:25833&BBOX=360000,5800000,374000,5815000&WIDTH=600 &HEIGHT=600&FORMAT=image/png Baumbestand GetFeatureInfo Gestaltplan http://www.digitaler-gestaltplan-potsdam.de/ogcservices/potsdam/wms?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetFeatureInfo&LAY ERS=gestaltplan&QUERY_LAYERS=gestaltplan&FEATURE_COUNT=50&x=500&y=400&SR S=EPSG:25833&bbox=361000.0,5802161.817,373772.53,5811534.229&WIDTH=600&HE IGHT=400&FORMAT=image/png DescribeLayer Gestaltplan http://www.digitaler-gestaltplan-potsdam.de/ogcservices/potsdam/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=DescribeLayer&LAYE RS=gestaltplan&outputFormat=application/json Web Feature Service GetCapabilities 1.0.0 GetCapabilities 1.1.0 GetCapabilities 2.0.0 Unterstützte Koordinatensysteme: 14 http://www.digitaler-gestaltplan-potsdam.de/ogcservices/potsdam/wfs?REQUEST=GETCAPABILITIES&SERVICE=WFS&VERSION=1.0.0&FO RMAT=text/xml http://www.digitaler-gestaltplan-potsdam.de/ogcservices/potsdam/wfs?REQUEST=GETCAPABILITIES&SERVICE=WFS&VERSION=1.1.0&FO RMAT=text/xml http://www.digitaler-gestaltplan-potsdam.de/ogcservices/potsdam/wfs?REQUEST=GETCAPABILITIES&SERVICE=WFS&VERSION=2.0.0&FO RMAT=text/xml EPSG:25832, EPSG:25833, EPSG:325833, EPSG:4258, EPSG:4326, EPSG:4839, CRS:84 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. 2.1. 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 CityGMLSpezifikation des OGC verwiesen. Die Dokumentation liegt dem mitgelieferten Datenträger bei und kann unter http://www.opengeospatial.org/standards/citygml heruntergeladen werden. Weitere Informationsquellen zum Thema CityGML, zu verfügbaren Softwaretools und aktuellen Entwicklungen finden sich auf dem CityGML Wiki unter http://www.citygmlwiki.org/index.php/Main_Page sowie auf der CityGML Homepage http://www.citygml.org/. 2.2. 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 3DModellierung, 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 2.4.1 gesondert betrachtet. 15 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 11.3.2011) Attributname FID Shape OBJECTID OBJEKTNAME OS OSBEZ FOLIE FOLIENBEZ DFIHO DFIHW DFIRW DFORM FOKHO FOKHW FOKRW TRAUH GESCHOSS GebH 16 Inhalt Feature ID (ArcGIS) Geometrietyp (Polygon) Weitere ObjektID Kodierte Objektadresse Objektschlüssel Objektschlüssel Klartext ALK Foliennummer (11 | 84) ALK Foliennummer Klartext Dachfirsthöhe in mm Dachfirst Hochwert in mm Dachfirst Rechtswert in mm Dachform Fußbodenoberkante in mm Fußbodenoberkante Hochwert in mm Fußbodenoberkante Rechtswert in mm Traufhöhe in mm Anzahl der Geschosse (aus Klimakonzept) Gebäudehöhe (aus Klimakonzept) Datentyp Integer Polygon Integer String String String Integer String Integer Integer Integer Integer Integer Integer Integer Integer Double Double Abbildung 7: Fortführungsworkflow LoD1-Stadtmodell Stadtmodell und Konzept LoD2 Fortführung Fortfü 17 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 SQLDeveloper 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 Tabelle 6: Prüf- und Filterbedingungen Bedingung Ergebnisshapefile OSBEZ = 'Tiefgarage' OR OSBEZ = 'unterirdische Gebäude' FOKHO > 0 AND TRAUH > 0 FOKHO = 0 AND TRAUH > 0 FOKHO = 0 AND TRAUH = 0 AND Geschoss > 0 Summe: FOKHO > 0 AND TRAUH = 0 Tiefgaragen, Gebäude Anz. Gebäude FOKHO < 0 OR TRAUH < 0 Negative_TRAUH_oder_FOKHO FOKHO = 0 AND TRAUH = 0 AND Geschoss = 0 Keine_Hoeheninformation unterirdische Hoeheninformation_VALK Hoeheninformation_nur_TRAUH Hoeheninformation_aus_AnzG Hoeheninformation_nur_FOKHO Folgeprozess 44 39355 36 2427 41862 17 1 6118 entfällt Daten sind bereit für Konvertierung FOKHO aus DGM ableiten FOKHO aus DGM ableiten und TRAUH berechnen: TRAUH = FOKHO + (Geschosszahl * 3) z.Z. nicht integriert, Prozess zur Erfassung der Höheninformation muss definiert werden z.Z. nicht integriert, Prozess zur Erfassung der Höheninformation muss definiert werden 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 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 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 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 41862 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 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 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 http://www.3dcitydb.net/ öffentlich verfügbar. 2.4. 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. 2.4.1. 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 Earth Globus abzufragen fragen und als Höhenwert für eine Positionierung der Gebäude zu verwenden. Damit wird eine optimierte Darstellung in Google Earth erreicht, weil die eigentliche Höhenlage der Gebäude dem schlechter aufgelösten Höhenmodell angepasst wird. Abbildung 11 stellt den Veröffentlichungprozess schematisch dar. 1. Exporteinstellungen Zum Export ist wieder der Importer/Exporter zu starten und eine Datenbankverbindung aufzubauen. Danach sind im Reiter die KML/ColladaKML/Collada Exporteinstellungen vorzunehmen. unehmen. Diese sind in die drei Hauptgruppen Rendering, Balloon und Höhe/Gelände unterteilt. In der Gruppe Rendering werden die Darstellungsoptionen eingestellt. Für die Visualisierung des LoD1-Modells Modells in Google Earth wird empfohlen, die in Abbildung 12 vorgenommen Einstellungen zu verwenden. Insbesondere hat sich die eingestellte Kantenseitenlänge von 200 Meter für die Ausspielung des Gesamtmodells bewährt. Die farbliche Ausgestaltung der Daten kann frei gewählt werden. Abbildung 13) kann In der Gruppe Balloon (Abbildung die Option „Placemark mit Description Abbildung 11: Veröffentlichung in Google Earth versehen“ aktiviert werden, um Attributinformationen bei der KML/Collada-Ausspielung KML/Collada Ausspielung darstellen zu können. Ist die Option aktiviert, muss ausgewählt werden, woher er die einzubindenden Informationen kommen. Dies kann entweder ein generisches Attribut in der Datenbank sein („Balloon_Content“) oder eine Konfigurationsdatei. Eine beispielhafte Konfigurationsdatei liegt dieser Dokumentation bei. Eine ausführliche Dokumentation Dokume zur Konfiguration von Ballons ist in dem Dokument 3DCityDB-Documentation Documentation-Addendum-v2_0_5.pdf enthalten. In der Gruppe Höhe/Gelände schließlich wird die Höhenbehandlung konfiguriert. Zur optimalen Darstellung wird die Verwendung der Option „Individuell „Individuell nach generischen Attribut „GE_LoDn_zOffset““ empfohlen. Dadurch wird die niedrigste Höhe des Google Earth Globus im Grundriss als Nullhöhe des Objektes definiert. Die eigentliche Gebäudehöhe, d.h. die in den Geometrietabellen festgelegten ZZ Werte bleiben ben von dieser Operation unbeeinflusst. 25 Abbildung 12: Darstellungsoptionen für den KML/Collada-Export Abbildung 13: Konfiguration von Balloons zur Ausgabe von Attributen in Google Earth Nach Konfiguration der KML/Collada-Einstellungen muss im Reiter KML/Collada Export (Abbildung 14) ein Speicherort und Dateiname für die Daten angeben werden. Typischerweise sollte der Export über den Live Workspace erfolgen. Abweichungen sind dann möglich, wenn eine Planungsvariante ausgespielt werden soll. Der Export kann bei Bedarf über eine Bounding Box auf Teilbereiche beschränkt werden. Die Optionen zur Kachelung sollte auf „Automatisch“ belassen werden, es sei denn, dass nur ein kleines 26 Gebiet (max. 1x1 km) ausgespielt wird, dann kann auf eine Kachelung komplett verzichtet werden. Zum Schluss ist die zu exportierende LoD-Stufe und die Darstellungsvariante zu wählen. Da aktuell im wesentlichen LoD1 Gebäude in der Datenbank vorliegen, ist diese auszuwählen. Als Darstellungsvariante wird „Geometrie“ empfohlen, die Sichtbarkeit sollte bei 150 Pixeln liegen. Der Export wird durch Anklicken des Export-Buttons gestartet. Abbildung 14: Exporteinstellungen der ausgelieferten Beispielausspielung Nach Abschluss der Ausspielung liegen im gewählten Zielverzeichnis die KML/Collada Daten. Im Fall, dass eine Kachelung erfolgte, handelt es sich um ein root-Dokument mit dem vergebenen Dateinamen und einer Anzahl von Kacheln mit zusätzlicher Kachelnummer. Zur Veröffentlichung in Google Earth sind diese Daten auf einen Webserver zu kopieren, der die Auslieferung von kml-, bzw. kmz-Dateien, unterstützt. Damit Nutzer den Datensatz aufrufen können, muss auf einer Webseite ein Link zu dem root-Dokument publiziert werden. 2.4.2. Export im CityGML Format Neben dem Export im KML/Collada-Format unterstützt der Importer/Exporter auch den Export im CityGML-Format. Im Gegensatz zum Export im KML/Collada-Format, bietet der CityGML-Export weniger Einstellmöglichkeiten, weil die Darstellung nicht konfiguriert werden muss. Deshalb ist der Export grundsätzlich ohne Anpassung von spezifischen Exporteinstellungen im Reiter Export möglich. Der Export kann auf Basis einer Bounding Box räumlich oder durch Eingabe kommaseparierter ID-Werte auf Einzelobjekte eingeschränkt werden. Wird keine Bounding Box oder ID angegeben, wird der gesamte 27 Datenbankinhalt ausgegeben. Eine wichtige, im Vorhaben entwickelte Erweiterung des Importer/ Exporters ist die Ausgabe der CityGML-Daten in unterschiedlichen Koordinatenreferenzsystemen. Damit eine Koordinatentransformation beim Export stattfinden kann, muss das Zielkoordinatensystem von Oracle unterstützt werden und zunächst im Reiter Voreinstellungen unter Datenbank eingestellt werden. Wählen Sie dazu die Option „Neues Referenzsystem“ aus und geben Sie die Oracle SRID ein. Durch Betätigung des „Prüfen“ Buttons wird geprüft, ob Oracle das Referenzsystem unterstützt. Ist dies der Fall wird im Log-Window eine Meldung ausgegeben, dass das System unterstützt wird (vgl. Abbildung 15). Vergeben Sie dann eine Beschreibung und klicken Sie auf „Übernehmen“ um das Koordinatensystem für den Export zu unterstützen. Abbildung 15: Koorindatenreferenzsysteme einstellen Nach Einstellung des Zielkoordinatensystems steht dieses im Exportdialog als Option zur Verfügung (vgl. Abbildung 16). 28 Abbildung 16: Exportdialog des Importer/Exporters Umfassende Dokumentationen zur Konfiguration des Importer/Exporters und zur Einstellung von Koordinatensystemen sind in den Dokumenten 3DCityDB-Documentation-v2_0.pdf und 3DCityDBDocumentation-Addendum-v2_0_5.pdf in den mitgelieferten Daten zu finden. 29 3. Zusammenführung Gestaltplan und 3D-Stadtmodell Die Aufbereitung der beiden Datensätze 3D-Stadtmodell und Digitaler Gestaltplan und die Bereitstellung von Veröffentlichungsworkflows und Schnittstellen sowie Fortführungsworkflows wurden immer mit dem weiterführenden Ziel konzipiert, eine kongruente 3D-Darstellung des Gestaltplanes zu realisieren. Deshalb wurde im Vorhaben besonderer Wert darauf gelegt, dass die Darstellung der Bestandgebäude im Gestaltplan und die LoD1-Gebäudemodelle auf der gleichen Datengrundlage - dem Kataster - beruhen und den gleichen Arbeitsstand zeigen. Das bedeutet, dass eine Aktualisierung des LoD1-Modells immer auch eine Aktualisierung der Klasse Bestandsgebäude im Gestaltplan nach sich zieht, damit die beiden Datensätze kongruent bleiben. Zugleich wurde durch Installation und Inbetriebnahme der 3D City Database als Datenhaltungskomponente für das Stadtmodell und die Entwicklung des shape2citygml-Konverters auch die Möglichkeit geschaffen, geplante Gebäude aus dem Gestaltplan direkt in die Stadtmodelldatenbank zu integrieren. Dazu werden zunächst alle Plangebäude im Gestaltplan selektiert und als separates Shapefile exportiert. Dieses Shapefile kann im LandXplorer Studio Professional als LoD1-Stadtmodell eingeladen werden und projektbezogen für eine Planvisualisierung verwendet oder über die Datenbankschnittstelle in die Datenbank geschrieben werden. Zur Integration in die Datenbank können über die Datenbankschnittstelle unterschiedliche Planungen und Planungsvarianten angelegt und verwaltet werden, die eine Trennung des Bestandsmodells (Live Datenbestand) vom Planungsmodell unterstützen. Dies erlaubt es, auch innerhalb einer Planung Bestandsgebäude zu löschen ohne den Live Datenbestand zu verändern. Diese Option, die auf dem Workspace Manager von Oracle beruht, erleichtert die kontinuierliche Erweiterung und Fortführung des Stadtmodells und davon abgeleiteter Planungsvarianten. Neben der Integration der Plangebäude in LandXplorer Studio Professional kann auch die Planzeichnung des Gestaltplanes als zusätzliche Geländetextur integriert werden. Dazu muss der entsprechende Ausschnitt des Gestaltplanes als TIFF aus ArcGIS exportiert werden und kann dann als Geländetextur in die Visualisierung eingebunden werden. Ebenso eignet sich der Datensatz Plangebiete als Referenzdatensatz um die Lage und Ausdehnung der Plangebiete in die Visualisierung zu integrieren. Die Abbildung 17 zeigt beispielhaft wie eine Integration aussehen könnte. 30 Abbildung 17: Beispielhafte Integration von Plangebäuden, Planzeichnung und Plangebietsabgrenzungen in LandXplorer Studio Professional 31 4. Übersicht der Daten, Softwarekomponenten und Skripte Die folgende Tabelle enthält eine Übersicht der mit dieser Dokumentation ausgelieferten Daten, Softwarekomponenten, Konfigurationsdateien und Skripte. Verzeichnis Dateiame Beschreibung CityGML Spezifikation 08007r1_City_Geography_Markup_Language_City GML_Encoding_Standard.pdf Potsdam_LoD1-LoD2.gml CityGML-Spezifikation (OGC) CityGML_Daten CityGML_Daten\CityGML_LoD 1-LoD3 Dokumentation KML_Collada_LoD1 Potsdam.gml Potsdam_LoD3.kml Potsdam_LoD3.kml + Kacheln KML_Collada_Projektdateien Potsdam Settings Recommendation.pdf KML_Collada_Projektdateien \Balloon_Styles BalloonSource_for_Potsdam.html BalloonSource_for_Potsdam_2.html BalloonSource_for_Potsdam_3.html EFRE-MARKE-1.jpg potsdam_400px.jpg weinberg in pariser blau.jpg Benutzerhandbuch_ProMIS_online.pdf Zugang ProMIS.docx Digitaler Gestaltplan.xml LoD1 Gebäudemodell.xml 3DCityDB-Documentation-Addendumv2_0_5.pdf 3DCityDB-Documentation-v2_0.pdf 3DCityDB-Importer-Exporter-1.3-Setup.jar Metadaten Software\ 3DCityDB_Importer_Exporter Digitaler_Gestaltplan_Potsdam.docx Potsdam_LoD1.kml + Kacheln Software\ArcGIS_Tools Potsdam.tbx Software\shape2citygml Software\shape2citygml\Proje ktdateien Shape2CityGML Konverter Dokumentation.pdf potsdam.shp2gml Potsdam_lod1.shp2gml PotsdamAdressdaten.xml STRASSEN_201006.csv shape2citygml-src.zip Software\shape2citygml\Quell code Software\shape2citygml\ shape2citygml SQL-Skripte 32 start_win.bat + mehrere Dateien und Verzeichnisse ETRS89_UTM32N_Bbg.sql ETRS89_UTM33N_Bbg.sql DELETE_BUILDING_BY_NAME_VERSIONED.sql DELETE_BUILDING_BY_ID_VERSIONED.sql CityGML Datei mit allen LoD1 und LoD2 Gebäuden zum Zeitpunkt des Projektes CityGML Datei mit zusätzlichen LoD3 Gebäuden aus dem Refina-Vorhaben Diese Dokumentation KML/Collada Ausspielung des LoD1 Modells KML/Collada Ausspielung des LoD3 Modells Einstellungen/Empfehlungen für den KML/Collada Export Mehrere Beispieltemplates zur Erzeugung von Balloons und verwendete Bilder für das Ballonlayout Benutzerhandbuch ProMIS Zugangsdaten ProMIS Metadaten Digitaler Gestaltplan Metadaten LoD1 Gebäudemodell Dokumentation zur 3DCityDB, zum Importer/Exporter und zu den im Vorhaben entwickelten Erweiterungen Installer für den Importer/Exporter und Datenbankskripte ArcGIS Toolbox zur Prüfung und Filterung der ALK Daten Dokumentation zum Konverter Projektdateien für die Konvertierung von ALK Daten in ein LoD1 Modell Quellcode des Konverters Shape2gml-Konverter Startdatei und Programmdateien SQL-Skripte zum Anlegen der Brandenburger ERTS89 Systeme in Oracle und zum Löschen von Gebäuden auf Basis des Attributes OBJEKTNAME bzw. der ID
