IMPLEMENTIERUNG VON WEBBASIERTEN GEOINFORMATIONSSYSTEMEN IN SERBIEN

Transkript

1 City of Čačak Stärkung des kommunalen Land Managements in Serbien IMPLEMENTIERUNG VON WEBBASIERTEN GEOINFORMATIONSSYSTEMEN IN SERBIEN Auf Grundlage der Erfahrungen aus dem Pilotprojekt in Čačak Dezember 2014 Dr. Joachim Benner

2 Studie im Auftrag des GIZ-Projektes Strengthening of the local land management in Serbia ausgeführt von: Ambero Consulting Icon Institute Representative Office Belgrad Kralja Milana Beograd, Srbija T belgrad@ambero.de

3 Gutachten zur Implementierung von webbasierten Geoinformationssystemen in Serbien Auf Grundlage der Erfahrungen aus dem Pilotprojekt in Čačak Version 1.0 Dr. Joachim Benner Dezember 2014

4 Inhaltsverzeichnis 1 Aufgabenstellung und Übersicht Anforderungen aus der INSPIRE Direktive Datenmodelle und Austauschformate für Landnutzungsdaten Allgemeine Anforderungen an ISO 191xx konforme Datenmodelle INSPIRE kompatible Datenmodelle für Landnutzungsdaten Datenmodell der Stadt Čačak - Analyse und Verbesserungsvorschläge Datenmodell Čačak, Version 1.0 (März 2014) Inhaltliche und formale Schwächen der Version 1.0 des Modells Datenmodell Čačak, Version 2.0 (September 2014) Konsequenzen aus der Nicht-Umsetzung der Vorschläge Vorschläge zur weiteren Vorgehensweise Überarbeitung und Ergänzung des Datenmodells Erprobung der Umsetzung des Datenmodells Zusammenfassung Referenzen Anhang A: Dokumentation des Datenmodells und der Verbesserungsvorschläge

5 1 Aufgabenstellung und Übersicht Die Stadt Čačak führt seit dem Jahr 2011 im Rahmen des GIZ-Vorhabens "Stärkung des kommunalen Landmanagements in Serbien" gemeinsam mit AMBERO/ICON ein Pilotprojekt zur Weiterentwicklung ihres kommunalen Landinformationssystems durch. Im Rahmen dieses Pilotprojektes wurde von der Stadt Čačak u. a. ein UML- Datenmodell zur konzeptionellen Modellierung von raumbezogenen Plänen entwickelt (Datenmodell Čačak, Version 1). Im Rahmen eines im April 2014 durchgeführten Workshops wurde dies Modell einer kritischen Analyse unterzogen, und es wurden Reihe konkrete Vorschläge zur formalen und inhaltlichen Überarbeitung gemacht. Im Laufe des Jahres 2014 wurde daraufhin von der Stadt Čačak die Version 2 des Datenmodells entwickelt. Entsprechend der Leistungsbeschreibung kann man den Inhalt dieses Gutachtens in folgenden Punkten zusammenfassen: Eine kurze Zusammenfassung der zeitlichen und inhaltlichen Anforderungen, die sich aus der Umsetzung der INSPIRE Direktive speziell für der Themenbereich "Raumbezogene Planung" ergeben (Kap. 2); Eine allgemeine Einführung in die formalen Anforderungen an ein ISO 191xx konformes Datenmodell (Kap. 3.1); Eine kurze inhaltliche Einführung in das INSPIRE Datenmodell für "Geplante Landnutzung" (INSPIRE PLU) (Kap. 3.2); Eine kurze Übersicht über Inhalt und Struktur der Version 1 des Datenmodells Čačak (Kap. 4.1) sowie die darin festgestellten und im Workshop angesprochenen Schwächen und Fehler (Kap. 4.2); Eine Zusammenfassung, inwieweit in Version 2 des Modells die angesprochenen Schwächen und Fehler korrigiert wurden (Kap. 4.3); Eine Wertung der zu erwartenden Konsequenzen, wenn das Datenmodell nicht noch weiter überarbeitet wird (Kap. 4.4); Vorschläge zur möglichen Vorgehensweise bei der Überarbeitung, Erprobung und Umsetzung des Datenmodells (Kap.5). Im Anhang A werden die auch in Version 2 noch festgestellten Schwächen und Fehler detailliert aufgelistet und konkrete Verbesserungsvorschläge formuliert. 2 Anforderungen aus der INSPIRE Direktive Die am 15. Mai 2007 in Kraft getretene INSPIRE (INfrastructure for SPatial InfoRmation in Europe) Richtlinie der Europäischen Union (EU 2007) zielt darauf, eine Europa-weite Geodateninfrastruktur zur Unterstützung gemeinsamer umweltpolitischer Entscheidungen aufzubauen. In der Praxis fordert INSPIRE eine einheitliche Beschreibung der Geodaten und deren Bereitstellung im Internet, mit Diensten für Suche, Visualisierung und Download. Auch die Daten selbst müssen in einem einheitlichen Format vorliegen. Die EU-Richtlinie, die von allen Mitgliedsländern binnen zwei Jahren in nationales Recht umgesetzt werden musste, definiert den rechtlichen Rahmen zum Aufbau der Geodateninfrastrukturen und definiert in drei Anhängen (Annex I - Annex III) die fachlichen Themen, die von der INSPIRE Richtlinie betroffen sind. Das Thema "Geplante Landnutzung" fällt dabei unter das INSPIRE Annex III Thema "Planned Land Use" (INSPIRE PLU). Fachliche und technische Einzelheiten zum Aufbau und zum Betrieb der Geodateninfrastrukturen regelt die EU mit 5 Durchführungsbestimmungen (Implementing Rules (IR)), die für die Mitgliedstaaten direkt verbindlich sind. Der Inhalt der IR wird im Weiteren kurz zusammengefasst. Metadaten sind Daten, die Geodaten und Geodatendienste einer Geodateninfrastruktur abstrahierend beschreiben. Sie unterstützen das Auffinden der benötigten Informationen und liefern wichtige Eigenschaften wie z.b. den Verwendungszweck. Die INSPIRE Durchführungsbestimmung zu Metadaten (EU 2008) trat am in Kraft, technische Details zur Bereitstellung werden in einem Begleitdokument festgelegt (INSPIRE 2013). Seit dem müssen Metadaten auch für die Datensätze der Annex III Fachthemen bereitgestellt werden. Die Durchführungsbestimmungen zur Interoperabilität von Geodatensätzen und diensten definieren einheitliche Datenmodelle für alle 34 INSPIRE-Geodatenthemen. Für das Annex III Thema INSPIRE PLU ist die Verordnung (EU 2013) relevant. Für die Umsetzung der Richtlinie gelten danach folgende Termine: Neu erhobene bzw. weitgehend umstrukturierte Geodatensätze müssen bis zum im INSPIRE Datenformat geliefert werden. Alle am vorhandenen Geodatensätze müssen bis im INSPIRE Datenformat geliefert werden. Ein Teil der technischen Architektur von INSPIRE besteht aus Infrastrukturkomponenten, deren konkrete Ausgestaltung in der Durchführungsbestimmungen zu den Netzdiensten (EU 2009, EU 2010) festgelegt ist. Bei den Komponenten handelt es sich um Geodatendienste zum "Suchen" und "Finden" von Geodatensätzen (Suchdienste), zum Visualisieren 5

6 von Geodatensätzen (Darstellungsdienste), und zum Herunterladen von Geodatensätzen (Downloaddienste). In zugehörigen Begleitdokumenten sind technische Details zur Implementierung von Suchdiensten (INSPIRE 2011), Downloaddiensten (INSPIRE 2013b) und Darstellungsdiensten (INSPIRE 2013c) festgehalten. Seit dem müssen die INSPIRE relevanten Datensätze zu Annex III Themen über Darstellungs- und Downloaddienste (z.z. aber noch nicht im INSPIRE Format) geliefert werden. In der INSPIRE Durchführungsbestimmung Data and Service Sharing werden die konkreten Anforderungen an Lizenzmodelle für die Bereitstellung von INSPIRE-Daten und -Dienste festgeschrieben. Die entsprechende Richtlinie (EU 2010a) ist seit in Kraft. Die Mitgliedstaaten sind verpflichtet, über den Aufbau und Betrieb ihrer Geodateninfrastruktur und den Stand der Umsetzung der INSPIRE-Richtlinie regelmäßig zu berichten. Hierfür werden jedes Jahr Kennzahlen zu den Infrastrukturelementen und -inhalten wie Geodatensätzen, Netzdiensten und den sie beschreibenden Metadaten erhoben, ausgewertet und veröffentlicht (Monitoring). Die entsprechende Verordnung der EU trat am in Kraft. 3 Datenmodelle und Austauschformate für Landnutzungsdaten Unter einem Datenmodell wird ganz allgemein eine formale Beschreibung der Objekte eines bestimmten Anwendungsbereiches sowie ihrer Eigenschaften (Attribute) und gegenseitigen Beziehungen (Relationen) verstanden. Man spricht von einem konzeptionellen Datenmodell, wenn diese Beschreibung unabhängig von einer konkreten Implementierung in einer allgemeinen Beschreibungssprache wie Unified Modelling Language (UML) (OMG 2014) vorgenommen wird. Der Vorteil der konzeptionellen Modellierung ist, dass aus einem derartigen Modell, ggf. mit automatisch arbeitenden Software-Werkzeugen wie ShapeChange (ShapeChange 2014), unterschiedliche Implementierungen wie Datenaustauschformate, Datenbankschemata oder Objektartenkataloge abgeleitet werden können. Die zentrale funktionale Anforderung an ein Datenmodell ist, dass es den vorgesehene Anwendungsbereich vollständig und problemgerecht abbilden muss. Für das vorliegende Projekt bedeutet dies, das Modell muss die Inhalte der relevanten Landnutzungspläne aus Serbien so abbilden können, dass alle vorgesehenen Anwendungen der digitalen Planwerke möglich sind. Dazu gehört insbesondere die automatische Transformation des digitalen Plans in das INSPIRE PLU Datenformat. Das Datenmodell darf sich dabei nicht nur auf einzelne ausgewählte Pläne beschränken. Für eine nachhaltige Nutzung sollten landesweit alle Planwerke eines bestimmten Typs (z.b. Bebauungspläne oder Flächennutzungspläne) abbildbar sein. Dies betrifft nicht nur bereits existierende, rechtskräftige Pläne, sondern alle nach den existierenden rechtlichen Rahmenbedingungen prinzipiell möglichen und sinnvollen Pläne. 3.1 Allgemeine Anforderungen an ISO 191xx konforme Datenmodelle Die Serie der Normen 19100ff der "International Organization for Standardization" (ISO 191xx) beschäftigt sich mit konzeptionellen Datenmodellen und Datenaustauschformaten für raumbezogene Daten. Es wird darin insbesondere eine Einschränkung des UML-Standards (ISO 191xx UML-Profil) festgelegt, das die automatische Ableitung eines XMLbasierten Datenaustauschformats aus dem UML-Modells gestattet. Die dabei erzeugten XML-Schemata bauen auf der ISO Norm Geography Markup Language (GML), Version auf, die gleichzeitig ein offizieller Standard des Open Geospatial Consortium (OGC) ist (OGC 2007) ist. Für die Transformation von UML nach XML-Schema legt die ISO Norm genaue Regeln fest. Die wichtigsten Regeln und Einschränkungen des ISO 191xx Profil werden im weiteren kurz erläutert. Zur Veranschaulichung dient dabei Abb. 1, das ein typisches, ISO-konformes UML-Modell zeigt. Regel 1: Das Datenmodell wird als UML-Klassendiagramm erstellt. Regel 2: UML-Paketen und UML-Elementen muss ein Stereotype zugewiesen werden (z.b. featuretype des UML- Elements FeatureClassA in Abb. 1). Dabei dürfen nur bestimmte Bezeichnungen verwendet werden, die ein UML- Element einer bestimmte konzeptionellen Kategorie zuordnen. Näheres dazu findet sich in Tabelle 1. Bei der Abbildung von UML nach XML-Schema ist jedem Stereotype eine eigene XML-Schema Vorlage zugewiesen. Regel 3: UML-Elemente können Attribute haben, denen zwingend ein Attribut-Typ zugewiesen werden muss. Die Attribut-Typen müssen entweder innerhalb des Datenmodells definiert sein (CodeListValue und EnumerationValue in Abb. 1), oder es muss ein in den ISO 191xx Normen definierter Typ verwendet werden (GM_Measure, GM_MultiSurface, Integer und CharacterString in Abb. 1). In Tabelle 2 sind einige der am häufigsten verwendeten ISO- Typen aufgeführt. Das vollständige Modell der verwendbaren Datentypen wird von der zuständigen Arbeitsgruppe ISO TC 211 als UML-Modell (ISO TC 211 Harmonized Model) im EnterpriseArchitect-Format bereitgestellt (ISO 2014). 6

7 Regel 4: Relationen zwischen UML-Elementen werden als navigierbare Assoziationen modelliert, denen zwingend ein Rollen-Name (relationname in Abb. 1) zugewiesen werden muss. Für die erlaubten Datentypen von Assoziations-Zielen gilt das Gleiche wie für Attribute, sie müssen entweder im Datenmodell selbst definiert oder im ISO Harmonized Model enthalten sein. Regel 5: Attributen und Assoziations-Zielen kann optional eine Kardinalität zugewiesen werden. Sie gibt an, ob ein Attribut / eine Assoziation optional oder verpflichtend ist, und ob sie einfach oder mehrfach belegt werden kann. Ist keine Kardinalität spezifiziert, wird das Attribut / die Assoziation als verpflichtend und einfach zu belegen definiert. Regel 6: Für UML-Pakete, UML-Elemente, Attribute von UML-Elementen und navigierbare Assoziationen ist ein Satz von Steuerparametern (Tagged Values) definiert, mit denen die Erzeugung des XML-Schemas aus dem UML-Modell im Detail festgelegt wird. Die wichtigsten Parameter sind in Tabelle 3 zusammengefasst. FeatureSuperClass + measureattribut: GM_Measure FeatureClassA + geometryattribut: GM_MultiSurface + intattribut: Integer + textattribut: CharacterString [0..1] +relationname 0..* FeatureClassB + codelistattribut: CodeListValue [0..1] + enumattribut: EnumerationValue [0..*] «enumeration» EnumerationValue «codelist» CodeListValue enumwert1 enumwert2 Abbildung 1. Beispiel eines ISO 191xx konformen UML-Modells Stereotype Relevant für Konzept applicationschema UML-Pakete Modelliert ein gesamtes GML-Anwendungsschema, das einen eigenen Namensraum hat und in Form einer XML-Schemadatei gespeichert wird. featuretype UML-Elemente Modelliert ein eigenständiges, evtl. raumbezogenes Objekt gemäß ISO datatype UML-Elemente Modelliert einen komplexen Datentyp als Aggregation von Attributwerten, der kein eigenständiges Objekt repräsentiert. enumeration UML-Elemente Modelliert eine feste Liste (Enumeration) von textuellen Bezeichnern, die innerhalb des Schemas definiert sind. Ein Attribut, dessen Datentyp den Stereotype enumeration hat, darf nur die in der Liste aufgeführten Werte annehmen. codelist UML-Elemente Modelliert eine flexible Liste (Codeliste) von textuellen Bezeichnern, die im Regelfall extern als GML-Dictionary gespeichert werden. Das UML-Modell kann Werte der Codeliste vorgeben, die allerdings jederzeit ergänzt werden können. Ein Attribut, dessen Datentyp den Stereotype codelist hat, darf nur die in der Liste aufgeführten Werte annehmen. Tabelle 1: Wichtige Stereotypes nach ISO Einfache Datentypen Measure Typen Datum und Uhrzeit Geometrie Typ Bedeutung Typ Bedeutung Typ Bedtg. Typ Bedeutung Integer Ganze Zahl Length Länge Date Datum GM_Object All. Geometrie Decimal Gleitkomma- Area Fläche Time Uhrzeit GM_Point Punkt 7

8 zahl CharacterString Zeichenkette Volume Volumen DateTime Datum / Uhrzeit GM_MultiPoint Boolean Wahrheitswert Angle Winkel (grad) GM_Curve URI Internet-URN Measure Wert mit Maßeinheit Tabelle 2: Häufig vorkommende Datentypen der ISO 191xx Normen GM_MultiCurve GM_Surface GM_MultiSurface Geometrie Multipunkt Geometrie Linien Geometrie Multilinien Geometrie- Flächen Geometrie Multiflächen Geometrie Tagged Value Relevant für Bedeutung targetnamespace applicationschema Namespace des erzeugten XML-Schemas xmlns applicationschema Namespace-Kürzel des erzeugten XML-Schemas xsddocument applicationschema Name der erzeugten XSD-Datei asdictionary codelist Ist asdictionary == true, wird die Codeliste als GML-Dictionary gespeichert. inlineorbyreference Attribute Assoziationen inline - Das referierte Objekt muss in das referierende Objekt eingebettet werden. byreference - Die Referenz kann nur über ein xlink erfolgen. inlineorbyreference - Beide Arten der Referenz sind möglich. sequencenumber Attribute Assoziationen Eine eindeutige Nummer, die die Reihenfolge der Elemente im XML-Schema festlegt. Tabelle 3: Wichtige Steuerparameter (Tagged Values) nach ISO INSPIRE kompatible Datenmodelle für Landnutzungsdaten Das in Čačak entwickelte Datenmodell der Landnutzungsdaten soll nicht nur die serbischen Pläne inhaltlich vollständig wiedergeben, es muss auch eine Transformation in das INSPIRE PLU Datenformat ermöglichen. Dazu muss die Struktur des serbischen Modells mit der INSPIRE Struktur kompatibel sein, und inhaltlich muss es möglich sein, zumindest alle verpflichtenden Attribute und Assoziationen der INSPIRE Objektklassen zu generieren. Um den aktuell vorliegenden Entwurf in dieser Hinsicht beurteilen zu können, wird das INSPIRE PLU Datenmodell im Weiteren kurz beschrieben. Die vollständige technische Spezifikation des Datenmodells findet sich in (INSPIRE 2013d), ein kompakter "Steckbrief" in (Richter & Krause 2013). Abb. 2 zeigt die Struktur des INSPIRE Datenmodells ohne Angabe der Attribute. Die Inhalte eines raumbezogenen Planwerks werden durch 4 Objektklassen modelliert: Die Klasse SpatialPlan modelliert einen raumbezogenen Plan als Ganzes. Verpflichtende Attribute der Klasse sind der räumliche Geltungsbereich des Plans (Flächengeometrie), die offizielle Bezeichnung des Plans (freier Text), die für die Planaufstellung zuständige Verwaltungsebene nach einem europaweit einheitlichen Klassifikationsschema, sowie eine nationale Klassifikation des Plantyps. Optional können u. A. noch Angaben zur zeitlichen Gültigkeit des Plans, ein Verweis auf die Plangrundlage, sowie Informationen zum ZoningElement SpatialPlan OfficialDocumentation SupplementaryRegulation Aufstellungsverfahren spezifiziert werden. Über Abbildung 2: Struktur des INSPIRE PLU Modells Assoziationen aggregiert ein SpatialPlan alle Objekte, die konkrete Planinhalte modellieren. Die Klasse ZoningElement modelliert raumbezogene Planinhalte der Zonierungsschicht. Diese Objekte definieren die primäre zulässige Landnutzung im Planungsgebiet. Sie müssen deshalb das gesamte Planungsgebiet überlappungsfrei überdecken. Verpflichtende Attribute der Klasse ZoningElement sind der Gültigkeitsbereich der Festlegung (Flächengeometrie), die Klassifikation der zulässigen Bodennutzung das einem europaweit einheitlichen Klassifikationsschema (HIerarchical Land Use Classification System - HILUCS), sowie eine Klassifikation der rechtlichen Verbindlichkeit der Festlegung. Optional können weitere Attribute spezifiziert werden, z.b. eine 8

9 zusätzliche, länderspezifische Klassifikation der zulässigen Bodennutzung, zeitliche Beschränkungen der Gültigkeit, sowie weitere numerisch oder textuell formulierte Einschränkungen. Die Klasse SupplementaryRegulation modelliert zusätzliche, raumbezogene Einschränkungen der zulässigen Bodennutzung, die die Objekte der Zonierungsschicht überlagern. Sie können eine beliebige Geometrie haben (verpflichtendes Attribut), und müssen nach einem speziellen, europaweit einheitlichen Schema klassifiziert werden (Hierarchical Supplementary Regulation Code List - HSRCL). Die Liste der optionalen Attribute ist weitgehend die Gleiche wie bei ZoningElement. Die Klasse OfficialDocumentation modelliert alle nicht-raumbezogenen Inhalte eines Plans. Diese können in drei Ausprägungen vorkommen, die auch miteinander kombiniert werden können: Als freier Text, als Verweis auf ein externes Dokument, sowie als Verweis auf eine gesetzliche Bestimmung. In den letzten beiden Fällen müssen eine Bezeichnung des referierten Dokuments bzw. Gesetzes sowie eine Internet-URL spezifiziert werden. 4 Datenmodell der Stadt Čačak - Analyse und Verbesserungsvorschläge 4.1 Datenmodell Čačak, Version 1.0 (März 2014) Die erste Version des Datenmodells, die dem im April 2014 durchgeführten Workshop zu Grunde lag, hat insgesamt 46 UML-Elemente. Davon haben 15 den Stereotype featuretype, modellieren also konkrete (raumbezogene oder nicht raumbezogene) Inhalte eines Landnutzungsplans. Die übrigen UML-Elemente repräsentieren komplexe Datentypen, Enumerationen und Codelisten, die als Typen von featuretype Attributen verwendet werden. Die featuretypes können wie folgt strukturiert und beschrieben werden: Klassen zur Modellierung des Plans als Ganzes (AdministrativeInformation und PlanObject). Bei der Attributierung beider Klassen hat man sich offensichtlich stark am INSPIRE PLU Datenmodell orientiert. Klassen zur Modellierung nicht-raumbezogener Inhalte des Plans: GraphicalInformation, TextualInformation, TextualRegulation und Raster. Klassen zur Modellierung raumbezogener Inhalte des Plans. Als Basisklasse dient die abstrakte Klasse PlanFeature, die von PlanObject referiert wird. Die Attributierung von PlanFeature ist konform mit dem INSPIRE PLU Datenmodell und ermöglicht insbesondere eine Unterscheidung in Zonierungsobjekte und überlagernde, zusätzliche Einschränkungen. Konkrete, raumbezogene Inhalte des Plans werden durch eine Anzahl von Klassen beschrieben, die (direkt oder indirekt) von PlanFeature abgeleitet werden: UrbanRegulationLine, UrbanRegulationArea, ConditionsAndConstraints, FunctionIndications, DimensioningIndications, ConstructionIndications, IndirectExecution. Die Klasse DevelopmentApplication soll (wahrscheinlich) Metadaten zu Applikationen verwalten, die auf die digitale Repräsentation des Plans zugreifen. 4.2 Inhaltliche und formale Schwächen der Version 1.0 des Modells Die formalen und inhaltlichen Schwächen des ersten Modellentwurfs, sowie eine Anzahl offener Fragen bezüglich der Bedeutung einzelner Teile des Datenmodells, werden im Weiteren kurz zusammengefasst. Formale Schwächen/Fehler F1 Es werden (mit Ausnahme der Geometrie-Attribute) nicht die korrekten ISO 191xx Bezeichnungen der Datentypen verwendet. Insbesondere wird häufig der Typ char (einzelner Character) für ein Textattribut verwendet. F2 Es fehlen im Regelfall bei Relationen die Namen der "navigierbaren" Assoziationsenden. F3 Es fehlen die für die automatische Transformation von UML nach XML-Schema notwendigen Steuerparameter. F4 Es fehlt generell die Dokumentation der UML-Elemente und Attribute innerhalb des UML-Diagramms. Deshalb ist die Bedeutung vieler Teile des Datenmodells unklar. F5 In einigen Fällen wird der Stereotype CodeList verwendet, obwohl es sich inhaltlich um DataTypes handelt (OtherTerritorialClassification, SurfaceIndication, VolumeIndication, Index, UnitIndication, OtherDimensioningIndication, HeightIndication. In den genannten UML-Elementen gibt es zudem Syntaxfehler bei der Attribut-Spezifikation. Inhaltliche Schwächen/Fehler/Offene Fragen I1 Es ist ungewiss, ob das vorliegende Datenmodell die Landnutzungspläne in Serbien adäquat wiedergeben kann, und gleichzeitig eine einfache und eindeutige Transformation in das INSPIRE Modell erlaubt. Das Modell wurde offensichtlich weitgehend aus dem europäischen Projekt Plan4All übernommen (Salvemini et al. 2011), und um 9

10 einige Konstrukte ergänzt. Das Plan4All Modell wurde ohne konkrete Berücksichtigung der Planungsgesetze und Planungspraxis in Serbien entwickelt. Es ist zudem niemals erprobt oder veröffentlicht worden, sondern diente ausschließlich zur Unterstützung der Entwicklung des INSPIRE PLU Datenmodells. Die verschiedenen, parallel genutzten Konzepte zur Klassifikation der Landnutzung (GeneralLandUseType, SpecificLandUseType, MacroClassificationOfLand, LUCAS_Code, Property) finden sich in der Art und Weise nicht im INSPIRE Datenmodell, und (eventuell) auch nicht in serbischen Landnutzungsplänen. Ähnliches gilt für die verwendeten Klassifikationsschemata für zusätzliche Einschränkungen (EasementType, ZoneTypeCode, ProtectionClassificationValue, HazardCategorieValue, InterventionCategorie), sowie für die CodeListe der Plantypen (PlanType). Während des Workshops wurde deshalb empfohlen, die verwendeten Klassifikationsschemata auf ihre Verträglichkeit mit der nationalen Planungspraxis zu überprüfen und sie ggf. anzupassen. Alternativ könnte auch die direkte Verwendung der INSPIRE Klassifikationsschemata (HILUCS, HSRCL) in Betracht gezogen werden. I2 Es gibt insgesamt sehr viele Pflichtattribute im Datenmodell, die in einigen Fällen in optionale Attribute umgewandelt werden sollten. Umgekehrt gibt es auch in einigen Fällen optionale Attribute, die eventuell besser als verpflichtend definiert werden sollten. Außerdem sind Attribute vielfach mehrfach belegbar, was in einigen Fällen zweifelhaft erscheint. I3 Der Unterschied zwischen den Klassen TextualRegulation und TextualInformation ist unklar, und es fehlt die Möglichkeit, ein Textdokument über eine URL zu referieren. I4 Die Bedeutung der Klassen Raster und GraphicalInformation ist unklar, und es fehlen Attribute zur inhaltlichen Ausgestaltung (z.b. die URL einer Rasterdatei). I5 Die Klasse PlanObject sollte von AdministrativeInformation abgeleitet werden, und nicht umgekehrt. I6 Die Vererbungs-Hierarchie der Klassen für raumbezogene Planinhalte erscheint sehr willkürlich. Einige der FeatureTypes aggregieren nur nicht-geometrische Attribute (DimensioningIndications, FunctionIndications, ConstructionIndications, IndirectExecution) und sollten konzeptionell in DataTypes umgewandelt werden. Alle konkrete Klassen für raumbezogene Planinhalte (UrbanRegulationArea, UrbanRegulationLine, ConditionsAndConstraints) könnten dann diese DataTypes verwenden. I7 Die Klasse UrbanRegulationArea erweckt durch das Attribut type (UrbanRegulationAreaType) den Anschein, dass Festlegungen der Landnutzung auf drei verschiedenen Ebenen der kommunalen Gliederung ("Parzelle", "Block" und "Zone") vorgenommen werden können. Es ist nicht klar, ob die Parzellen im Plandokument mit den Parzellen nach Grundbuch identisch sind, die in einem separaten Katasterplan modelliert werden und in einem Plandokument nicht noch einmal definiert werden dürfen. Es ist weiterhin nicht klar, ob in einen bestimmten Plandokument gleichzeitig Festlegungen auf verschiedenen, sich räumlich überlagernden Ebenen vorkommen können, und was diese Gliederung mit den verschiedenen Schemata zur Nutzungs-Klassifikation (s. Abbildung 3) zu tun hat. Wenn eine Mischung von Parzellen, Block- und Zonen-Ebene möglich ist, müssen unbedingt genaue Regeln definiert werden, welche Prioritäten es bei überlagernden Festlegungen gibt. Um eine eindeutige Abbildung auf das INSPIRE PLU Format zu ermöglichen muss spezifiziert werden, ob eine UrbanRegulationArea im zugehörigen Plandokumnet zur Zonierungs-Schicht gehört (isoverlayarea == false) oder eine zusätzliche Einschränkung darstellt (isoverlayarea == true). buildingparcel(0...1): SpecificLandUseType urbanzone(1...*): buildingparcel urbanblock(1...*): buildingparcel urbanzone(1): GeneralLandUseType urbanblock(1): SpecificLandUseType Abbildung 3: Kommentar im Datenmodell Čačak 10

11 4.3 Datenmodell Čačak, Version 2.0 (September 2014) Zwischen April und August 2014 wurde das Datenmodell von der Stadt Čačak überarbeitet. Inwieweit dabei die in Kap. 4.1 aufgeführten Schwächen beseitigt wurden, wird im weiteren kurz zusammengefasst. Eine ausführliche Dokumentation der in Version 2.0 des Datenmodells noch vorhandenen Schwächen und Fehler, sowie eine Anzahl von Verbesserungsvorschlägen, findet sich im Anhang A. Formale Schwächen/Fehler F1 Die Korrektur ist unvollständig und scheint sich auf einige Klassen (PlanObject, TextualInformation, TextualRegulation, Raster) zu beschränken. F2 Keine Korrektur erfolgt F3 Keine Korrektur erfolgt F4 Keine Korrektur erfolgt F5 Keine Korrektur erfolgt Inhaltliche Schwächen/Fehler/Offene Fragen I1 Bei den Attributen und verwendeten Codelisten sind keine Änderungen gegenüber der vorhergehenden Version festzustellen. I2 Änderungen bei der Kardinalität von Attributen sind nur bei wenigen Klassen (PlanObject, PlanFeature, Raster, TextualRegulation, TextualInformation) feststellbar. I3 TextualInformation wurde um einige Attribute ergänzt, die Bedeutung ist jetzt insgesamt klarer. I4 Raster wurde um ein Attribut (Referenz auf Rasterdatei) ergänzt, die Bedeutung und Anwendung von GraphicalInformation ist weiterhin unklar. I5 Wurde korrigiert. I6 Die Vererbungshierarchie und die Stereotype wurden in 3 Fällen geändert (FunctionIndications, DimensioningIndications, UrbanRegulationArea), dadurch wurden allerdings neue, noch gravierendere Fehler eingebaut. Die genannten Klassen haben jetzt gar keine Verbindung mehr zu PlanObject und PlanFeature und können praktisch nicht mehr verwendet werden. I7 Keine Änderung feststellbar. 4.4 Konsequenzen aus der Nicht-Umsetzung der Vorschläge Die formalen Fehler machen zumindest die Erzeugung eines GML-kompatiblen XML-Schemas aus dem UML-Modell unmöglich, dies kann weder automatisch noch manuell erfolgen. Die manuelle Ableitung eines Datenbankschemas könnte prinzipiell möglich sein. Durch die fehlende Dokumentation ist die Erprobung und praktische Umsetzung des Modells, sowie die Entwicklung unterstützender Software sehr erschwert. Der Problemkomplex I1 ist sehr gravierend. Es ist nicht sichergestellt, ob das Datenmodell die Inhalte serbischer Landnutzungspläne tatsächlich vollständig abbilden kann. Genauso kann es aber auch sein, dass Konstrukte im Modell enthalten sind, die weder für die nationalen Pläne noch für INSPIRE wirklich benötigt werden. Dies würde das Gesamtmodell unnötig komplizieren und die Abbildung nach INSPIRE erschweren. Wegen der vielen parallel verwendeten Klassifizierungsschemata der Landnutzung ist derzeit die Definition eindeutiger Abbildungsregeln vom nationalen Modell auf das INSPIRE Modell fast unmöglich. Ungünstig definierte Kardinalitäten von Attributen (I2) können sich unterschiedlich auf die Brauchbarkeit des Datenmodells auswirken. Wenn eine Klasse ein Pflichtattribut hat, dessen Wert nach den vorliegenden Informationen unbekannt ist, kann dies die schemakonforme Darstellung eines vorhandenen Landnutzungsplans verhindern. Umgekehrt können nicht belegte oder zu häufig belegte Attribute dazu führen, dass bestimmte Applikationen nicht genügend Informationen oder nicht-eindeutige Informationen haben. Die im Problemkomplex I6 angesprochenen Klassen sind zentral für die Modellierung von raumbezogenen Planinhalten. Ohne eine Änderung der Modellierung der Version 2 des Datenmodells lässt sich kein Plan abbilden. Die alte Version 1 könnte prinzipiell eingesetzt werden, hätte aber starke funktionale Einschränkungen. 5 Vorschläge zur weiteren Vorgehensweise Ein mögliches Nachfolgeprojekt sollte die folgenden beiden thematischen Schwerpunkte haben: Die Überarbeitung und Ergänzung des in Čačak entwickelten Datenmodells, und Die praktische Erprobung der Umsetzung des Datenmodells. 11

12 Für jeden dieser Bereiche werden Vorschläge zur inhaltlichen Ausgestaltung und zur möglichen Vorgehensweise gemacht. 5.1 Überarbeitung und Ergänzung des Datenmodells Bevor eine Version 3.0 des Datenmodells entwickelt wird, sollte zunächst auf nationaler Ebene in Serbien geklärt werden, welche konkreten Ziele mit der Entwicklung des Datenmodells verfolgt werden. Es ist in Anbetracht des mit der Entwicklung verbundenen Aufwandes wenig sinnvoll, das Datenmodell nur für die Unterstützung der INSPIRE Richtlinie, nur für eine einzelne Kommune wie Čačak und nur für einen einzigen Typ von Landnutzungsplänen zu entwickeln. Stattdessen könnte man anstreben, dass langfristig auf allen Ebenen der öffentlichen Verwaltung die Landnutzungspläne in einem standardisierten, objektorientierten Format erfasst, ausgetauscht, bereitgestellt und archiviert werden. Zu klären wäre weiterhin, ob und in welchem Umfang diese Daten dann zukünftig routinemäßig in Verwaltungsverfahren (z.b. Beteiligungs- oder Genehmigungsverfahren) eingesetzt werden sollen. Ein weiterer, vor einer erneuten Überarbeitung des Datenmodells zu klärender Fragenkomplex betrifft Struktur und Inhalt der existierenden Pläne. In einer ausführlichen Studie sollten die folgenden Fragen beantwortet werden: Welche inhaltliche Vorgaben (Pflichtinhalte, optionale Inhalte, Klassifikations-Schemata, verwendete Indikatoren) machen die gesetzlichen Bestimmungen der raumbezogenen Planung in Serbien? Welche Inhalte werden in existierenden Plänen tatsächlich verwendet? Dazu sollte unbedingt Beispielpläne mehrere Kommunen aus unterschiedlichen Regionen berücksichtigt werden. In welcher Art und Weise (analog oder digital) liegen die rechtsgültigen Pläne aktuell vor? Für die praktische Erprobung (s.u.) sollte ein repräsentativer Satz digitaler Beispielpläne zur Verfügung stehen. Welche Software-Werkzeugen werden in Serbien typischerweise zur Erstellung oder Fortschreibung digitaler Pläne verwendet, und in welchen Formaten werden die erzeugten Pläne aktuell archiviert? Ist in nächster Zukunft mit der Neu-Aufstellung oder Änderung existierender Pläne zu rechnen? Welche Darstellungsvorschriften werden in verschiedenen Kommunen verwendet? Dem Projektteam, das diese Studie durchführt bzw. begleitet, sollten Planungsexperten verschiedener Kommunen bzw. Planungsregionen, Rechtsexperten auf nationaler Ebene sowie IT-Experten angehören. Auf Basis der Ergebnisse der Studie sollte das Datenmodell dann ein weiteres Mal überarbeitet und ergänzt werden. Am Ende sollte idealerweise die folgenden Dokumente existieren: Ein formal korrektes und vollständig dokumentiertes UML-Modell, dass prinzipiell die gesetzlichen Vorgaben / Pflichtinhalte unterstützt und alle in der Studie betrachteten Beispielpläne abbilden kann. Eine Anzahl von Codelisten zur Spezifikation der zulässigen Landnutzung sowie zur Spezifikation zusätzlicher Regulierungen und Einschränkungen. Das XML-Schema des Austauschformats, sowie GML-Dictionaries zur XML-Repräsentation der Codelisten. Beides kann automatisch aus dem UML-Modell generiert werden. Ein informell dokumentierter Satz von Regeln, die das serbische Datenformat für Landnutzungspläne auf das INSPIRE PLU Format abbilden. Ein informell dokumentierter Satz von Darstellungsvorschriften für die Klassen und Attribute des serbischen Datenformats. 5.2 Erprobung der Umsetzung des Datenmodells Zentraler Bestandteil eines Nachfolgevorhabens sollten Pilotprojekte zur praktischen Erprobung des Datenmodells sein. Die Pilotprojekte müssen auf Basis vorhandener, rechtskräftiger oder in Aufstellung befindlicher Landnutzungspläne durchgeführt werden und verfolgen folgende Ziele: Die Klärung der Frage, ob existierende, digitale Landnutzungspläne überhaupt in ein objektorientiertes Format überführt werden können, und in welchem Umfang die Pläne dazu überarbeitet oder neu erfasst werden müssen. Sollte sich herausstellen, dass in der Mehrzahl der Fälle eine größere Überarbeitung notwendig ist, müssten Empfehlungen erarbeitet werden, welche Software-Werkzeuge in Zukunft zur Planerstellung genutzt werden sollten, und wie diese Werkzeuge zu verwenden sind. Dafür sollten auch geeignete Schulungsmaßnahmen initiiert werden. Der praktische Nachweis, ob das entwickelte Datenformat existierende Pläne tatsächlich abbilden kann, und eine eindeutige Transformation in das INSPIRE PLU Datenformat prinzipiell ermöglicht. Gegebenenfalls müssen als Resultat der Erprobung das Datenmodell nochmals überarbeitet und die Abbildungsvorschriften zur Erzeugung von INSPIRE PLU geändert oder erweitert werden. Die Entwicklung einer Anzahl von Software-Bausteinen zur Unterstützung des Abbildungs-Prozesses. Im Rahmen des Projektes können wahrscheinlich nur prototypische Lösungen generiert werden, die für den späteren Einsatz im Regelbetrieb der Verwaltung noch überarbeitet und erweitert werden müssen. 12

13 Abbildung 4 zeigt schematisch eine Systemarchitektur, wie sie im Rahmen eines Nachfolgevorhabens aufgebaut werden könnte. Sie unterstützt verschiedene Teilprozesse, die evtl. durch separate Pilotprojekte realisiert werden könnten: Beispielhafter Export existierender Pläne in das Datenformat ESRI Shapefile. Die Verwendung dieses Datenformats bietet sich an, da es von fast allen Fachsystemen der raumbezogenen Planung unterstützt wird und eine objektorientierte Struktur realisiert. Lässt sich ein existierender Datensatz ohne (größeren) Informationsverlust im Shapefile-Format exportieren, dann wird er sich prinzipiell auch auf ein GML-basiertes, objektorientiertes Datenformat abbilden lassen. Beispielhafte Transformation der Shapefile Pläne in das neu-entwickelte nationale Datenformat. Da im Rahmen des Pilotprojektes die Beispielpläne auf jeweils unterschiedliche Shapefile-Strukturen abgebildet werden, benötigt dieser Prozessschritt eine flexibel konfigurierbare Transformations-Software. Hierfür sind verschiedene, prinzipiell geeignete Software-Werkzeuge verfügbar, u. a. das kommerzielle System Feature Manipulation Engine (FME) (SAFE 2014), die freie Software HUMBOLDT Alignment Editor (HALE) (HALE 2014), oder die Spezialentwicklung GML- Toolbox (KIT 2014), die in einer speziellen Variante zur Erprobung des MonPlanGML Datenformats (Benner et al. 2008) der Republik Montenegro verwendet worden ist. Integration der Beispielpläne in eine nationale Geodateninfrastruktur (GDI). In dem Zusammenhang müssen verschiedene Teilprobleme gelöst werden: Auswahl und Installation eines geeigneten WebGIS Systems; Ableitung eines Datenbank-Schemas aus neu entwickelten Datenmodell, automatische Überführung eines XML-basierten Plans in die Datenbank, und Verbreitung des Plans über geeignete Web-Services. Neben einem reinen Darstellungsdienst, wie er für einen speziellen Plan schon realisiert wurde (Čačak 2014), sollte auch die Einrichtung von Download-Diensten und Web Feature Services untersucht werden. Automatische Transformation der Beispielpläne in das Format INSPIRE PLU. Dazu müssen die informell spezifizierten Abbildungsregeln formalisiert und von einer geeigneten Software umgesetzt werden. Letzteres kann prinzipiell mit den aufgeführten Werkzeugen zur Transformation Shapefile Serbisches Datenmodell durchgeführt werden. Integration der Beispielpläne im Datenformat INSPIRE PLU in die Europäische GDI. Hierbei handelt es sich prinzipiell um die gleiche Technologie wie in der nationalen GDI. Es müssen aber die Anforderungen der Umsetzungs-Richtlinien (Kap. 2) bezüglich der unterstützten Dienste und der Performance Anforderungen beachtet werden. Plan Export ESRI Shapefile Plan Plan Export Export ESRI Shapefile ESRI Shapefile Transformation Nationales Datenformat Nationale GDI Plan Export ESRI Shapefile Transformation INSPIRE PLU Europäische GDI Abbildung 4: Systemarchitektur zur prototypischen Überführung existierender Pläne in das neu entwickelte Datenformat 13

14 6 Zusammenfassung Im Rahmen des GIZ-Vorhabens "Stärkung des kommunalen Landmanagements in Serbien" wurde von der Stadt Čačak zusammen mit AMBERO/ICON ein UML-basiertes Datenmodell für Landnutzungspläne entwickelt. Dabei stand die Unterstützung der EU Richtlinie INSPIRE im Themenbereich Landnutzungsplanung im Vordergrund. Im Rahmen dieser Studie wurden dies Datenmodell begutachtet und inhaltliche Vorschläge für ein Nachfolgeprojekt erarbeitet. Zu diesem Zweck wurden zunächst die formalen und inhaltlichen Anforderungen an das Datenmodell zusammengestellt, die sich aus der INSPIRE Richtlinie sowie aus den ISO 191xx Normen ergeben. Die in den beiden Versionen des Datenmodells festzustellenden formalen Fehler und inhaltlichen Schwächen wurden dokumentiert und bewertet. Auf dieser Basis wurden abschließend inhaltliche Vorschläge für ein Nachfolgeprojekt unterbreitet, die sich wie folgt zusammenfassen lassen: Eine Klärung, welche weitere Ziele - neben der Unterstützung von INSPIRE - auf nationaler Ebene mit der Entwicklung des Datenmodells verfolgt werden; Eine Studie über die gesetzlichen Rahmenbedingungen und die etablierte Praxis bei der Landnutzungsplanung in Serbien; Die Überarbeitung des entwickelten Datenmodells auf Basis der in der Studie dokumentierten Vorschläge; Die praktische Erprobung des Datenmodells an Hand einer Anzahl repräsentativer Beispielpläne. Dazu müssten insbesondere prototypische Software-Werkzeuge zur Überführung existierender, digitaler Landnutzungspläne aus verschiedenen serbischen Kommunen/Regionen in das standardisierte serbische Datenformat und das europäische Format INSPIRE PLU entwickelt werden. Weiterhin sollte prototypisch eine Geodateninfrastruktur zur Verbreitung dieser Daten (im nationalen und europäischen Datenformat) über standardisierte Web Services aufgebaut werden. 7 Referenzen Benner, J., Eichhorn, T., Krause, K.-U., Müller, Y. 2008: MonPlanGML - GML-based Data Model for Muncipal Land Management in Montenegro. In: Schrenk/Popovich/Engelke/Elisei (Eds.) "Proc. REAL CORP 2008", Wien, , pp Čačak 2014: GUP Grada Čačka. Zuletzt aufgerufen EU 2007: Richtlinie 2007/2/EG des Europäischen Parlaments und des Rates vom 14. März 2007 zur Schaffung einer Geodateninfrastruktur in der Europäischen Gemeinschaft (INSPIRE). Zuletzt aufgerufen EU 2008: Verordnung (EG) Nr. 1205/2008 der Kommission vom 3. Dezember 2008 zur Durchführung der Richtlinie 2007/2/EG des Europäischen Parlaments und des Rates hinsichtlich Metadaten. Zuletzt aufgerufen EU 2009: Verordnung (EG) Nr. 976/2009 der Kommission vom 19. Oktober 2009 zur Durchführung der Richtlinie 2007/2/EG des Europäischen Parlaments und des Rates hinsichtlich der Netzdienste. Zuletzt aufgerufen EU 2009a: Entscheidung der Kommission vom 5. Juni 2009 zur Durchführung der Richtlinie 2007/2/EG des Europäischen Parlaments und des Rates hinsichtlich Überwachung und Berichterstattung. Zuletzt aufgerufen EU 2010: Verordnung (EU) Nr. 1088/2010 der Kommission vom 23. November 2010 zur Änderung der Verordnung (EG) Nr. 976/2009 hinsichtlich Downloaddiensten und Transformationsdiensten. Zuletzt aufgerufen EU 2010a: Verordnung (EU) Nr. 268/2010 der Kommission vom 29. März 2010 zur Durchführung der Richtlinie 2007/2/EG des Europäischen Parlaments und des Rates in Bezug auf den Zugang der Organe und Einrichtungen der Gemeinschaft zu Geodatensätzen und -diensten der Mitgliedstaaten nach harmonisierten Bedingungen. Zuletzt aufgerufen EU 2013: Verordnung (EU) Nr. 1253/2013 der Kommission vom 21. Oktober 2013 zur Änderung der Verordnung (EU) Nr. 1089/2010 zur Durchführung der Richtlinie 2007/2/EG hinsichtlich der Interoperabilität von Geodatensätzen und - 14

15 diensten. Zuletzt aufgerufen HALE 2014: HUMBOLDT Alignment Editor. Zuletzt aufgerufen INSPIRE 2011: Technical Guidance for the implementation of INSPIRE Discovery Services, Version Zuletzt aufgerufen INSPIRE 2013: INSPIRE Metadata Implementing Rules: Technical Guidelines based on EN ISO and EN ISO 19119, Version 1.3, Zuletzt aufgerufen INSPIRE 2013a: D2.8.III.4 Data Specification on Land Use Technical Guidelines, Version Zuletzt aufgerufen INSPIRE 2013b: Technical Guidance for the implementation of INSPIRE Download Services, Version Zuletzt aufgerufen INSPIRE 2013c: Technical Guidance for the implementation of INSPIRE View Services, Version Zuletzt aufgerufen INSPIRE 2013d: D2.8.III.4 Data Specification on Land Use Technical Guidelines, Version Zuletzt aufgerufen ISO 2014: ISO/TC 211 Harmonized Model. Zuletzt aufgerufen KIT 2014: GML-Toolbox. Zuletzt aufgerufen OGC 2007: OpenGIS Geography Markup Language (GML) Encoding Standard, Version 3.2.1, OGC Zuletzt aufgerufen OMG 2014: Object Management Group - Unified Modeling Language (UML ). Zuletzt aufgerufen Richter, W., Krause, K.-U. 2013: Steckbrief zum INSPIRE Anhang III Nr. 4 Thema Bodennutzung, Version Zuletzt aufgerufen am Safe 2014: Internet Präsentation der Firma SAFE SOFTWARE. Zuletzt aufgerufen Salvemini, M., Vico, F., Iannucci, C. (Editors) 2011: Plan4all Project Interoperability for Spatial Planning. Zuletzt aufgerufen ShapeChange 2014: ShapeChange - Processing application schemas for geographic information. Zuletzt aufgerufen

16 Anhang A: Dokumentation des Datenmodells und der Verbesserungsvorschläge A1: Modellierung des Plans als Ganzes «enumeration» CoreMetadata - Plan:: HierarchyLev elname spatialplan.country spatialplan.state spatialplan.regional spatialplan.subregional spatialplan.supralocal spatialplan.local spatialplan.sublocal spatialplan.other Administrativ einformation + hierarchylevelname: HierarchyLevelName + organisationname: char + plandescription: string [0..1] + plantype: PlanType + processstepgeneral: ProcessStepGeneral + temporalextentto: Date [0..1] «voidable» + ordinancedate: Date [1..*] + ordinanceref: string [1..*] + processstepspecific: ProcessStepSpecific + temporalextentfrom: Date ProcessStepSpecific + adopted + approved + counterdeducations + draft + earlyinvolvementpublicauthorities + earlypublicparticipation + involvementpublicauthorities + municipalstatute + planpreparationdecision + publicobservations + revision «enumeration» ProcessStepGeneral elaboration adoption legalforce obsolete PlanObj ect + geometry: GM_Aggregate + title: CharacterString «voidable» + legislationreference: CharacterString +replaces PlanType + bindinglanduseplan + detailedregulationplan = srp + executivedevelopmentplan + generalregulationplan = srp + generalurbanplan = srp + landscapeplan + municipalityspatialplan = srp + municipaloperationplan + municipalstructureplan + parcellationproject = srp + preparatorylanduseplan + regionalspatialplan = srp + republicserbiaspatialplan = srp + specialpurposeareaplan = srp + statedevelopmentplan + structurevisionplan + urbanproject = srp + zoningplan Abbildung 5: Datenmodell Čačak, Version 2 Verbesserungsvorschläge Beide Enden der Assoziation von PlanObject mit sich selbst müssen einen Namen haben AdministrativeInformation: Datentyp string CharacterString AdministrativeInformation: Datenyp char CharacterString PlanObject: Datentyp GM_Aggregate GM_MultiSurface PlanType: Reduktion der Einträge auf die spezifischen Plan-Typen in Serbien, sowie Elimination der Zuweisungen "=srp". Dies führt bei der automatischen Ableitung eines GML-Dictionaries zu Fehlern. Überprüfung, ob die in ProcessStepSpecific aufgeführter Prozessschritte nach der nationalen Planungspraxis alle relevant sind, und ggf. Elimination nicht benötigter Einträge. 16

17 AdministrativeInformation + hierarchylevelname: HierarchyLevelName + ordinancedate: Date [0..*] + ordinanceref: CharacterString [0..*] + organisationname: CharacterString + plandescription: CharacterString [0..1] + plantype: PlanType + processstepgeneral: ProcessStepGeneral + processstepspecific: ProcessStepSpecific [0..1] + temporalextentfrom: Date [0..1] + temporalextentto: Date [0..1] +isreplacedby 0..* PlanObject + geometry: GM_MultiSurface + legislationreference: CharacterString [0..1] + title: CharacterString +replaces 0..1 Abbildung 6: Mögliche alternative Modellierung A2 Modellierung nicht-raumbezogener Planinhalte 17

18 CoreMetadata - Plan:: LanguageCode + eng + srp GraphicalInformation + language: LanguageCode = srp + title: char 0..* 1 Raster AdministrativeInformation PlanObj ect +replaces filetype: RasterFileType [0..1] + name: CharacterString [0..1] + refdocument: URI [0..1] 0..* 1 + geometry: GM_Aggregate + title: CharacterString «voidable» + legislationreference: CharacterString RasterFileType + bitmap + ecw + geotiff + jpg + pdf + png + tiff TextualInformation 0..* + date: Date [0..1] - filetype: DokumentFileType [0..1] + language: LanguageCode [0..1] = srp + name: CharacterString + refdocument: URI [0..*] 0..* TextualRegulation + language: LanguageCode [0..1] = srp + title: CharacterString Abbildung 7: Datenmodell Čačak, Version 2 Verbesserungsvorschläge Alle navigierbaren Enden von Assoziationen müssen einen Namen haben Die Codeliste DocumentFileType muss definiert werden Raster: Das Attribut refdocument sollte die Kardinalität 1..* haben GraphicalInformation: Die Klasse sollte eliminiert werden 18

19 +replaces isreplacedby 0..* +refplan 1 AdministrativeInformation PlanObject + geometry: GM_MultiSurface + legislationreference: CharacterString [0..1] + title: CharacterString +refplan 1 +refplan 1 +refrasterfile 0..* Raster + filetype: RasterFileType [0..1] + name: CharacterString [0..1] + refdocument: URI [1..*] +refdocument 0..* TextualInformation + date: Date [0..1] + filetype: DocumentFileType [0..1] + language: LanguageCode [0..1] = srp + name: CharacterString + refdocument: URI [0..*] +reftext 0..* TextualRegulation + language: LanguageCode [0..1] = srp + title: CharacterString RasterFileType + bitmap + ecw + geotiff + jpg + pdf + png + tiff DocumentFileType + doc + pdf + txt CoreMetadata - Plan::LanguageCode + eng + srp Abbildung 8: Mögliche alternative Modellierung A3: Oberklasse PlanFeature für raumbezogene Planinhalte AdministrativeInformation PlanObject + geometry: GM_Aggregate + title: CharacterString «voidable» + legislationreference: CharacterString 1 0..* PlanFeature replaces * 0..* «enumeration» RegulationNature generallybinding bindingfordevelopers bindingonlyforauthorities nonbinding TextualRegulation + language: LanguageCode [0..1] = srp + title: CharacterString + geometry: GM_Aggregate + isoverlayarea: boolean + regulationnature: RegulationNature «voidable» + regulationreference: char [1..*] + status: PlanFeatureStatus 1 PlanFeatureStatus + existing + planned + removal Abbildung 9: Datenmodell Čačak, Version 2 Verbesserungsvorschläge Alle navigierbaren Enden von Assoziationen müssen einen Namen haben PlanFeature sollte auch eine Relation zu TextualInformation haben Die Attribute geometry und isoverlayarea sollten in abgeleiteten Klassen definiert werden 19

20 Datentyp char CharacterString PlanFeatureStatus + existing + planned + removal PlanFeature + regulationnature: RegulationNature + regulationreference: CharacterString [0..1] + status: PlanFeatureStatus [0..1] = planned «enumeration» RegulationNature generallybinding bindingfordevelopers bindingonlyforauthorities nonbinding +refplanfeature 1 +refdocument 0..* TextualInformation + date: Date [0..1] + filetype: DocumentFileType [0..1] + language: LanguageCode [0..1] = srp + name: CharacterString + refdocument: URI [0..*] +refplanfeature 1 +reftext 0..* TextualRegulation + language: LanguageCode [0..1] = srp + title: CharacterString DocumentFileType + doc + pdf + txt Abbildung 10: Mögliche alternative Modellierung A4: Klassen zur Modellierung raumbezogener Planinhalte A4.1 Modellstruktur ConditionsAndConstraints IndirectExecution PlanFeature UrbanRegulationArea FunctionIndications UrbanRegulationLine ConstructionIndications DimensioningIndications Abbildung 11: Datenmodell Čačak, Version 2 Verbesserungsvorschläge 20

21 Die Klassen UrbanRegulationArea, FunctionIndications, ConstructionIndications, DimensioningIndications und IndirectExecution müssen entweder (direkt oder indirekt) von PlanFeature abgeleitet werden, oder über Attribute bzw. Assoziationen von PlanFeature referiert werden. Bei der derzeitigen Modellierung ist eine Verwendung der Klassen unmöglich. Auch die Klassen IndirectExecution und ConstructionIndications sind konzeptionell DataTypes und sollten diesen Stereotype haben. Um unabhängig voneinander eine mögliche Landnutzung festzulegen (FunctionIndications) und Beschränkungen der Art der Bebauung vornehmen zu können (ConstructionIndications), sollte ConstructionIndications nicht von FunctionIndications abgeleitet werden. IndirectExecution ConditionsAndConstraints FunctionIndications PlanFeature UrbanRegulationArea ConstructionIndications UrbanRegulationLine DimensioningIndication Abbildung 12: Mögliche alternative Modellierung A4.2 FeatureType UrbanRegulationArea UrbanRegulationArea + description: string [0..1] = URL, text,... + label: char [0..*] + type: UrbanRegulationAreaType [0..*] UrbanRegulationAreaType + buildingparcel + urbanblock + urbanzone UrbanRegulationArea + geometry: GM_MultiSurface + type: UrbanRegulationAreaType + description: CharacterString [0..1] + label: CharacterString [0..*] + functionalindications: FunctionIndications + constructionindications: ConstructionIndications [0..1] + dimensionalindications: DimensioningIndication [0..*] + indirectexecution: IndirectExecution [0..1] + isoverlayarea: Boolean UrbanRegulationAreaType + buildingparcel + urbanblock + urbanzone Abbildung 13: Datenmodell Čačak, Version 2 Abbildung 14: Mögliche alternative Modellierung 21

22 Verbesserungsvorschläge UrbanRegulationArea sollte konzeptionell die flächenhaften Festlegungen und Einschränkungen der Landnutzung repräsentieren. Dementsprechend werden die folgenden Änderungen am Datenmodell empfohlen: Transfer des Geometrie-Attributs (geometry) von der Oberklasse PlanFeature in die Klasse UrbanRegulationArea, und Beschränkung auf Flächengeometrie (GM_MultiSuface). Spezifikation der kommunalen Regulierungsebene (Attribut type) als einfaches Pflichtattribut. Transfer von isoverlayarea in die Klasse UrbanRegulationArea, und Spezifikation als einfaches Pflichtattribut, um die INSPIRE PLU Abbildung sicherzustellen. Ergänzung von Attributen zur Spezifikation funktionaler Einschränkungen der Landnutzung (functionindications, einfaches Pflichtattribut), zur Einschränkung von Art und Maß der baulichen Nutzung (dimensionalindications, optional, mehrfach), und zur Spezifikation von Einschränkungen der Bauweise (constructionindications, optional, einfach). Die Notwendigkeit der Attribute label und indirectexecution sollte überprüft werden, da ihre Bedeutung unklar ist. A4.3 FeatureType UrbanRegulationLine UrbanRegulationLine PlanFeature UrbanRegulationLine PlanFeature + description: CaharacterString [0..1] - geometry: GM_MultiCurve + indirectexecution: IndirectExecution [0..1] + type: UrbanRegulationLineType [0..*] + geometry: GM_MultiCurve + type: UrbanRegulationLineType + description: CharacterString [0..1] + indirectexecution: IndirectExecution [0..1] + dimensioningindications: DimensioningIndications [0..1] UrbanRegulationLineType + constructionline + constructionline.ground + constructionline.storey + constructionline.underground + parcellationline + regulationline UrbanRegulationLineType + constructionline + constructionline.ground + constructionline.storey + constructionline.underground + parcellationline + regulationline Abbildung 15: Datenmodell Čačak, Version 2 Abbildung 16: Mögliche alternative Modellierung Verbesserungsvorschläge Spezifikation des Attributs type (UrbanRegulationLineType) als einfaches Pflichtattribut Ergänzung eines Attributs zur Einschränkung von Art und Maß der baulichen Nutzung (dimensionalindications, optional, mehrfach). Die Notwendigkeit des Attributs indirectexecution sollte überprüft werden, da seine Bedeutung unklar ist. 22

23 A4.4 FeatureType ConditionsAndConstraints ConditionsAndConstraints Abbildung 17: Datenmodell Čačak, Version 2 PlanFeature + constraintdescription: string [0..*] + constraintname: char [0..*] + easementtype: EasementTypes [0..*] + interventiontype: InterventionCategory [0..*] + naturalrisksafetyarea: HazardCategoryValue [0..*] + protectedsite: ProtectionClassificationValue [0..*] + restrictionzone: ZoneTypeCode [0..*] ConditionsAndConstraints Abbildung 18: Mögliche alternative Modellierung PlanFeature + geometry: GM_Object + constraintname: CharacterString [0..1] + constraintdescription: CharacterString [0..*] + dimensioningindications: DimensioningIndications [0..1] + indirectexecution: IndirectExecution [0..1] + protectedsite: ProtectionClassificationValue [0..1] + naturalrisksafetyarea: HazardCategoryValue [0..1] + restrictionzone: ZoneTypeCode [0..1] + easementtype: EasementTypes [0..1] + interventiontype: InterventionCategory [0..1] Die Klasse ConditionsAndConstraints repräsentiert konzeptionell zusätzliche Einschränkungen der zulässigen Landnutzung, die einen beliebigem Raumbezug haben können. Diese Einschränkungen können aus fünf verschiedenen thematischen Bereichen kommen: Spezielle Dienstbarkeiten oder Landnutzungsrechte (easementtype, Enumeration EasementTypes); Schutzgebiete oder Schutzobjekte (protectedsite, Enumeration ProtectionClassificationValue); Spezielle städtebauliche Maßnehmen oder Eingriffe (interventiontype, Codeliste InteventionCategory); Gebiete mit speziellen Risiken oder Sicherheitsanforderungen (naturalrisksafetyarea, Codeliste HazardCategoryValue); Gebiete mit speziellen Regulierungen (restrictionzone, Codeliste ZoneTypeCode). Ein konkretes Objekt ConditionsAndConstraints kann nur eine einzige Einschränkung aus einer der fünf thematischen Bereiche repräsentieren. Die Kardinalität der entsprechenden Attribute sollte deshalb auf jeden Fall von 0..* auf 0..1 reduziert werden. Noch besser wäre es, für jeden Typ von Einschränkungen eine spezielle, von ConditionsAndConstraints abgeleitete Klasse (vom Stereotype featuretype) zu definieren. A5 Komplexe Datentypen Die in Kap. A4 diskutierten Klassen für raumbezogene Inhalte nutzen als Attributtypen verschiedene komplexe Datentypen, die in diesem Kapitel kommentiert werden. Dabei wird vor allem auf die syntaktische Korrektheit der Spezifikation eingegangen, und weniger auf inhaltliche Aspekte. Es wird generell eine Überprüfung empfohlen, ob die verwendeten Klassifikationen und Indikatoren auch tatsächlich im Rahmen der Raumplanung in Serbien benötigt werden, und ob noch andere Indikatoren verwendet werden. A5.1 FunctionIndications FunctionIndications + generallandusetype: GeneralLandUseType [0..*] + indirectexecution: boolean + interventiontype: InterventionCategory [0..*] + LUCAS_code: char [0..1] + macroclassificationofland: MacroClassificationOfLand [0..1] + otherterritorialclassification: OtherTerritorialClassification [0..*] + property: Property [0..1] + specificlandusetype: SpecificLandUseType [0..*] FunctionIndications + specificlandusetype: SpecificLandUseType [0..*] + generallandusetype: GeneralLandUseType [1..*] + property: Property [0..1] + LUCAS_code: CharacterString [0..1] + macroclassificationofland: MacroClassificationOfLand [0..1] + otherterritorialclassification: CharacterString [0..1] + interventiontype: InterventionCategory [0..*] + indirectexecution: Boolean Abbildung 19: Datenmodell Čačak, Version 2 Abbildung 20: Mögliche alternative Modellierung 23

24 Verbesserungsvorschläge Eine Klassifikation generallanduse sollte verpflichtend sein, um eine eindeutige Abbildung auf die INSPIRE Klassifikation HILUCS zu gewährleisten. Der LUCAS_Code (falls tatsächlich benötigt) und die otherterritorialclassification sollten vom Typ CharacterString sein, oder durch spezielle Codelisten definiert werden. Die Bedeutung des Boolean Attributs indirectexecution ist unklar. A5.2 DimensioningIndications DimensioningIndications + heightindications: HeightIndication [0..*] + indexes: Index [0..*] + otherindications: OtherDimensioningIndication [0..*] + surfaceindications: SurfaceIndication [0..*] + unitindications: UnitIndication [0..*] + volumeindications: VolumeIndication [0..*] HeightIndication +...(freetext)(m): float + maxheight: float OtherDimensioningIndication +...(freetext): float + landusagedegree: float SurfaceIndication +...(freetext)(m2): float + grossconstructionarea: float + grossstoreyarea: float UnitIndication +...(freetext): float + grosshousingdensity: float + maxnumberofapartments: float + maxnumberofstoreys: float + nethousingdensity: float VolumeIndication +...(freetext)(m3): float + cubiccapacity: float Index +...(freetext): float + constructionindex: float + occupancyindex: float Abbildung 21: Datenmodell Čačak, Version 2 24

25 Verbesserungsvorschläge Die als Attributtypen verwendeten Codelisten (Stereotype codelist) sind in Wirklichkeit komplexe Datentypen (Stereotype datatype) In diesen Datentypen kommen auch Attribute vom Typ Integer (maxnumberofappartments, maxnumberofstoreys) und Attribute mit physikalischer Maßeinheit (z.b. maxheight, grossconstructionarea) vor Es wird generell ein an INSPIRE PLU angelehnte Datenstruktur (Abbildung 22) empfohlen. DimensioningIndicationRealValue + value: Decimal DimensioningIndication + indicationreference: DimensioningIndicationValue DimensioningIndicationMeasureValue + value: Measure DimensioningIndicationValue + ConstructionIndex + OccupancyIndex + GrossConstructionArea + GrossStoreyArea + CubicCapacity + NetHousingDensity + GrossHousingensity + MaxNumberOfAppartments + MaxNumberOfStoreys + LandUsageDegree + MaxHeight DimensioningIndicationIntegerValue + value: Integer DimensioningIndicationTextValue + value: CharacterString Abbildung 22: Mögliche alternative Modellierung A5.3 ConstructionIndications ConstructionIndications FunctionIndications + otherconstructionindications: OtherConstructionIndications [0..*] + roofshape: RoofShape [0..*] + typeofbuilding: TypeOfBuilding [0..*] ConstructionIndications + typeofbuilding: TypeOfBuilding [0..*] + roofshape: RoofShape [0..*] + otherconstructionindications: OtherConstructionIndication [0..*] Abbildung 23: Datenmodell Čačak, Version 2 Abbildung 24: Mögliche alternative Modellierung 25

26 Verbesserungsvorschläge Die Attributierung von ConstructionIndications ist formal korrekt, konzeptionell sollte das UML-Element aber als datatype modelliert werden. A 5.4 IndirectExecution IndirectExecution + ordinancedate: Date [0..*] + ordinanceref: string [0..*] + processstepgeneral: ProcessStepGeneral [0..1] + title: char [0..1] IndirectExecution + title: CharacterString [0..1] + processstepgeneral: ProcessStepGeneral [0..1] + ordinanceref: CharacterString [0..*] + ordinancedate: Date [0..*] Abbildung 25: Datenmodell Čačak, Version 2 Abbildung 26: Mögliche alternative Modellierung Verbesserungsvorschläge Eine Modellierung als datatype anstelle von featuretype wird empfohlen. Der Datentyp CharacterString sollte anstelle von string und char verwendet werden. Die Klasse modelliert offensichtlich auf Ebene einzelner Planinhalte Angaben zum Verfahren der Planaufstellung. Es ist unklar, ob auf dieser Ebene die Attribute title, ordinancedate und ordinancereference tatsächlich relevant sind. Im INSPIRE PLU Datenformat gibt es diese Daten nur auf Ebene des gesamten Plans. Im Čačak Datenmodell werden auf Planebene (AdministrativeInformation, PlanObject) die Attribute von IndirectExecution einzeln verwendet, was von der Modellierung her inkonsistent ist. Es ist nicht einsichtig, warum die Klasse als "IndirectExecution" bezeichnet wurde. Eine besserer Klassenname könnte z.b. "OrdinanceInformation" sein. 26

27

28