Regeln für Teilnehmer:
Ich bin mit den Regeln einverstanden

Übersicht:

Favoritenliste:

Favourite Pages

There are currently no pages on your favourites list. You can add pages to this list by selecting Favourite from the Tools menu on the page you're viewing.
Child pages
  • Erstellung von B-Plan Metadaten zu jedem einzelnen B-Plan
Skip to end of metadata
Go to start of metadata

Hallo zusammen, seitens Schleswig Holstein ist die Frage aufgekommen, ob zu jedem einzelnen B-Plan/ F-Plan usw. ein einzelner Metadatensatz angelegt werden muss. Ich habe schon in diversen Bundesländerkatalogen geschaut und so wirklich einheitlich scheint das deutschlandweit noch nicht gemacht zu werden. Gibt es seitens dieser Diskussionsrunde dort ein Meinungsbild bzw. eine praktikable Lösung oder Struktur. Ich hatte nur gefunden, dass in Hamburg jeder Plan einzeln erfasst wird. Für Anregungen und Hilfe wäre ich sehr dankbar. Wenn diese Frage schon an anderer Stelle beantwortet wurde bitte ich um Entschuldigung und würde mich freuen wenn Sie mir die Seite nennen könnten. Vielen Dank im Vorraus.

  • No labels

8 Comments

  1. Letztlich ist dies eine Frage, wie Sie Ihre B-Plan-Daten für INSPIRE organisieren (möchten):

    Falls Sie jeden einzelnen B-Plan als in sich abgeschlossenen Datenbestand betrachten, wäre dieser in Konsequenz auch mit einem eigenem Metadatensatz zu beschreiben (und mittels Diensten mit wiederum eigenen Metadaten bereitzustellen). Im Hinblick auf die daraus resultierende hohe Anzahl von Metadatensätzen und die umfangreichen (wenn nicht unbrauchbaren) Suchergebnisse bei Katalog-Recherchen ist dies sicherlich nicht zielführend.

    Für sinnvoller halte ich es, die B-Pläne mindestens einer Gemeinde (oder sogar eines Landkreises) als einen gemeinsamen Datenbestand zu betrachten und diesen auch mit einem gemeinsamen Darstellungs- sowie Downloaddienst bereitzustellen. Dies würde pro "Einheit" drei Metadatensätze ergeben, die in Summe m.E. nutzerfreundlicher und bei Katalog-Recherchen wesentlich besser zu handhaben sind. Die Zusammenfassung von B-Plänen in einem gemeinsamen Darstellungsdienst bietet sich ohnehin an, da sicherlich niemand für jeden einzelnen B-Plan einen weiteren Dienst in sein GIS hinzuladen möchte.

     

  2. Dem muss ich leider etwas widersprechen (wink) . Aus Sicht der Nutzer einer GDI - insbesondere Kommunen und Planungsbüros, ist die Modellierung als einzelne Datensätze sehr sinnvoll. Man kann jeden Plan recherchieren und in sein GIS laden. In vielen Bundesländern ist das auch seit Jahren so in den Verwaltungsprozessen etabliert.

    Infos zum Vorgehen in RP, SL und teilweise HE - HH macht es auch so ähnlich:

    http://www.geoportal.rlp.de/metadata/Leitfaden_kommunale_Plaene_GDI_RP.pdf

    Zum aktuellen Thema Offenlagen:

    http://www.geoportal.rlp.de/portal/fileadmin/user_upload/Download/Dokumente/Anleitung_Offenlage_GeoPortal.rlp.pdf

     

    Beispiel für BPlan im OpenData Portal RP:

    https://daten.rlp.de/organization/stadt_andernach

    https://daten.rlp.de/dataset/2ec3dac0-1a81-833e-bdfa-a4b2bbf61dd6/resource/a207c5fc-2d05-f840-c432-1a0de24340fa_geoportalrlp_mobile

    Für weitere Infos stehe ich gerne zur Verfügung.

     

     

     

  3. In Berlin treibt uns diese Frage auch um: Wir hatten die Diskussion über die Zulässigkeit der Modellierung eines (1) B-Plan-Datensatzes für das Land Berlin mit Links zur Festsetzung als Sachdatenattribut bei jedem Geltungsbereich eines einzelnen B-Planes drei Fragen weiter unten eröffnet  Geplante Bodennutzung (Planned Land Use).

    Die kompakte Modellierung macht auch u.E. Sinn. Die Zulässigkeit ist mir unklar geblieben. 

  4. In Baden-Würrtemberg wurde die Diskussion um die Granularität ebenfalls geführt. Im Ergebnis wurde in einer fachl. Arbeitsgruppe entschieden, dass je Datensatz (= einzelner B-Plan) ein Metadatensatz erfasst und über je einenen Darstellungs- und einen Downloaddienst bereitsgestellt werden soll. Grund hierfür ist die Tatsache, dass vordergründig kleinräumige Anwendungsfälle identifiziert wurden. Darüber Hinaus könnenweitere Dienste angeboten werden in denen mehrere B-Pläne zusammengefasst werden (je nach vorliegendem Anwendungsfall). Für eine Automatisierung bei der Erzeugung von Metadaten und Dienste zu den B-Plänen werden mit diesem Vorgehen (ein B-Plan = 1 Datensatz = 1 Dienst) ebenfalls Vorteile identifiziert.

  5. Aus Sicht des Fachnetzwerks Bodennutzung ergibt sich allein aus der „Data Specification on Land Use“ die fachlich begründete Sicht, dass ein Bauleitplan bzw. ein Planungsdokument als eigenständiger Datensatz aufzufassen ist: „The planned land use conceptual schema (…) corresponds to a DATASET that corresponds to a spatial planning document.“ (siehe Nr. 5.3.1.1.5 Planned land use im Technical Guidance Document). Voraussetzung seitens INSPIRE ist allerdings, dass eine gewisse rechtliche Bindung am Planungsdokument hängt: „Only the spatial planning documents that are or have to be legally adopted by an authority and are opposable to third parties are considered within INSPIRE“.

    Diese Sichtweise ist auch aus der Betrachtung, im Rahmen von E-Government-Prozessen mit derartigen raumbezogenen Informationen arbeiten zu wollen, zwingend erforderlich, da jeder wirksame (F-Plan) bzw. bestandskräftige (B-Plan) Plan ebenso wie Dokumente im Rahmen von Planfeststellungsverfahren eigenständige Ressourcen mit entsprechend erforderlichen eigenständigen Ressourcenbezeichnern darstellen. Im Umfeld der Bauleitpläne obliegt die Zuständigkeit alleinig den Kommunen; somit stellt jeder Bebauungsplan ein eigenständiges Ortsgesetz dar, sollte demnach auch eigenständig adressierbar sein, und beinhaltet natürlich auch für seinen jeweiligen Geltungsbereich individuelle attributive Fachinformationen, welche somit in Metadaten abzubilden sind. Hinzu kommt, dass innerhalb der kommunalen Familie zudem unterschiedliche Policies bezüglich der Nutzungsbestimmungen zu derartigen Datensätzen vergeben werden können, denn auch dieses Feld fällt in den Bereich kommunaler Selbstverwaltung.

    Die INSPIRE-Modellierung berücksichtigt genau diese Sachverhalte, indem eindeutig auf genau ein Planungsdokument als eigenständiger Geodatensatz verwiesen wird.

    Daher findet sich dieser fachlich motivierte Ansatz in der GDI-RP (vgl. die obigen Anmerkungen von Armin Retterath) ebenso wie in der GDI-BW, welcher jeweils in entsprechenden Handlungsempfehlungen festgeschrieben ist:

    RP:

    http://www.geoportal.rlp.de/metadata/Leitfaden_kommunale_Plaene_GDI_RP.pdf

    Die auf einen Einzelplan bezogene Granularität ergibt sich durch Verweis auf INSPIRE sowie durch die im Einzelnen detalliert beschriebene, diese fachliche Sichtweise abbildende Modellierung.

    BW:

    https://www.geoportal-bw.de/documents/20147/0/GESAMT_Leitfaden_Bauleitpl%C3%A4ne_GDI-BW_2017-12-06+V_2_0.pdf/c03c4ccf-f5aa-f488-c25f-f84cd3c51491

    Seite 9: Jeder Bauleitplan stellt einen Geodatensatz nach § 3 Abs. 1 LgeoZG dar.

     

    Im übrigen findet sich diese granulare Sichtweise auch in der Modellierung für digital erstellte Pläne im Standard XPlanung wieder.

     

    Da im Umfeld der GDI-DE dieses Thema in der Vergangenheit vor dem Hintergrund der somit zu erwartenden hohen Anzahl an INSPIRE-relevanten Geodatensätzen stets kontrovers diskutiert wurde und mglw. zu Überlegungen führen mag, diesbezügliche Geodatensätze aggregiert bereit zu stellen, sei an dieser Stelle nochmals hervorgehoben, dass bei einer Bereitstellung zugunsten Dritter ggf. anzutreffende unterschiedliche Nutzungsbestimmungen ebenso wie die einzelplanbezogenen Metadaten berücksichtigt werden müssen.

  6. Bei uns in der GDI-NI hatten wir es den Kommunen frei gestellt, wie sie ihre Planungsdaten beschreiben. Über die Jahre hat sich nun folgendes Vorgehen etabliert, welches sowohl von kommunaler Seite, aus der GDI-Sicht und auch im Hinblick auf die Änderungen im BauGB als praktikabel herausgestellt haben.

    1. Gemeinde erfasst einen (parent) Metdatensatz zu "den Bebauungsplänen in der Gemeinde".  - Die INPSPIRE-Pflicht für die Bereitstellung von Metadaten ist erfüllt. Gemeinde gewinnt Zeit.
    2. Gemeinde erfasst auf Basis dieses Metadatensatzes nach und nach für alle Einzelpläne jeweils einen Metadatensatz (children). Im Idealfall kann hier bei den Tansferoptionen bereits auf den Plan im Internet verlinkt werden. - Die Gemeinden finden es oft hilfreich, durch die Erfassung selbst einen Überblick über die z. T. sehr alten Pläne mit zig Änderungen zu erhalten. Vielen ist auch wichtig, auf die jeweils geltende BauNVO im Metadatensatz Bezug zu nehmen. Bei einigen war das Datum der Rechtskraft der Pläne "verschollen". Kommunale Gebietsreformen haben die Sortierungen durcheinander gewirbelt usw. All diese Info-Defizite können also durch die systematische Erfassung behoben werden. Oft ist dies ein monatelang voranschreitender Prozess, was auch mich zuerst sehr verwundert hat. Es wird jedoch klar, wenn man sich unser GDI-Credo vor Augen hält: "Setzt INSPIRE so um, dass Ihr selbst davon einen Nutzen habt!!"
    3. Sofern die Gemeinde es für erforderlich hält, werden auf Basis der Einzelpläne die jeweiligen Änderungen zum Einzelplan erfasst (children).

    Aus Sicht von INSPIRE brauchen alte Pläne (vor dem 10.12.2013) nicht unbedingt in das INSPIRE-Datenmodell überführt zu werden (kommt ja einer Neuerfassung gleich, deswegen ist es nicht gefordert), weswegen diese Pläne als AtomFeed-Downloaddienst bereitgestellt werden können. Ein WFS wird also nicht zwingend benötigt. Stelle ich Pläne jedoch als AtomFeed bereit, so benötige ich für jeden Plan einen Metadatensatz (Daten-Service Kopplung). Für das neue BauGB sollen neue Pläne nun auch veröffentlicht werden. Außerdem liegt es auch im Eigeninteresse zumindest unserer Kommunen, eGovernment zu befördern und es Ihren Bürgern möglichst einfach zu machen, auf solche Daten zuzugreifen. Auch hierfür können also einzelne Metadatensätze hilfreich sein, um die Pläne dann in das entsprechende Portal zu bringen.

    Als neuster Trend werden die Metadaten für Einzelpläne automatisiert hergestellt. Hierzu wird in der Regel auf die Infos in den B-Plan GIS, die im Einsatz sind, zurückgegriffen. Die dortigen Informationen werden angereichert mit den weiteren Elementinhalten für den Metadatensatz. Im Idealfall hat die Gemeinde dafür sogar einen eigenen CSW. In dem stehen dann nicht nur B-Pläne sondern auch alle Metadaten für die Flächennutzungsplanung und ich kann mir vorstellen, dass es nicht mehr lange dauert, bis auch Wirtschaftswege, Beleuchtungskataster, Gemeindestraßen usw. dort zu finden sind.

    Ein weiterer Trend geht dahin, die Metadateninhalte für Einzelpläne (und weitere Geodaten) für Apps zu benutzen oder aber wenigstens die eigene Webseite mit diesen Infos zu ergänzen. So müssen nur die Metadaten aktualisiert werden. Apps und Webseite bleiben stehts unverändert. ("Das ist ja praktisch!")

     

    Ich kann dem allgemeinen "Suchchaos", welches immer wieder heraufbeschworen wird, nicht zustimmen: Aufgrund des hinterlegten Regionalschlüssels und / oder des vorhandenen ParentIdentifierts in den Metadaten können sämtliche B-Pläne akkurat inhaltlich voneinander getrennt dargestellt werden und z.B. auf die B-Pläne in einer Gemeinde, einer Samtgemeinde oder einem Landkreis bezogen werden. Je nachdem, wie es benötigt wird. Dass dies derzeit in der Regel nicht gelingt, liegt nicht an den zahlreichen vorhandenen Metadaten, sondern an der Unzulänglichkeit sämtlicher vorhandener Suchoberflächen.

    Ich bin schon jetzt gespannt, wie sich die Service-Metadaten für die Planungsdaten entwickeln werden. Bei ihnen ist dann zu beachten, dass die Daten-Service Kopplung sauber eingebaut werden kann. Für uns als Kst. GDI-NI zeichnet sich ab, dass es ein friedliches Nebeneinander von Diensten mit Originalplänen und Diensten mit INSPIRE-Datenmodell Bodennutzungs-Daten geben wird. Je nachdem, wie weit ein Datenhalter ist, wird er die Metadaten entsprechend mit "inspireidentifiziert" kennzeichnen oder die Kennzeichnung herausnehmen, denn wirklich kennzeichnen muss er letzten Endes nur die "Bodennutzung". Die Metadaten zu seinen Plänen aber bleiben ihm und können vielfältig genutzt werden.

  7. Aus Sicht der Architektur der GDI-DE ist insbesondere zu gewährleisten, dass die Lebenszeitintervalle und Rechtstände von Plänen, sowie die Nutzungsbedingungen bzw. Ansprechpartner in den Metadaten abgebildet werden können. Zunächst ist hier die Ebene des Einzelplanes geeignet, die unterschiedlichen Angaben dezentral bereitzustellen (vgl. Kommentar von Herrn Walter). Soweit die kommunale Betroffenheit gegeben ist, sind die B-Pläne für INSPIRE mit Metadaten zu beschreiben und entsprechend als Darstellungs- und Downloaddienst bereitzustellen. Wie die Architektur dabei die INSPIRE-Umsetzung unterstützen kann oder dies Auswirkungen auf die Architektur hat, können wir auch nochmal in der Sitzung des AK Architektur Mitte Juni thematisieren.

    Hier sollten Sie für Ihren Anwendungsfall das Architekturkonzept in Ihrer Länder-GDI prüfen, insbesondere das Konzept der Datenhaltung und Datentransformation in der GDI-SH, sowie die Möglichkeit der aggregierten Bereitstellung transformierter INSPIRE-Datensatzserien (im INSPIRE-Zielmodell), jeweils unter Berücksichtigung der bereits genannten Anforderungen.

  8. Ich möchte mich auf diesem Wege schon einmal für die umfangreichen Antworten  bei Ihnen bedanken. Der Input ist sehr hilfreich um auch für uns die bestmöglichste Konstellation aufzubauen.