Was ist ein kommunales Geoportal und wofür braucht man es?
Definition und Abgrenzung
Ein Geoportal ist in Deutschland sogar gesetzlich definiert: Es ist eine elektronische Kommunikations-, Transaktions- und Interaktionsplattform, die über Geodatendienste (und weitere Netzdienste) den Zugang zu Geodaten ermöglicht. [1]
Das Wort „kommunales Geoportal“ beschreibt im Kern genau dieses Prinzip, nur mit kommunalem Fokus: Eine Stadt, ein Landkreis oder ein Zweckverband stellt darüber Karten, Datensätze und Dienste aus verschiedenen Fachbereichen (z. B. Umwelt, Planung, Verkehr, Liegenschaften) zentral bereit, statt sie in einzelnen Fachverfahren oder Insellösungen zu verstecken. Eine gute Einordnung liefert auch die deutsche GDI-Praxis: Geoportale dienen als zentrale Kommunikations- und Zugangsplattform zwischen Datenanbietenden und Nutzenden.
Wichtig zur Abgrenzung: Ein Geoportal ist nicht nur eine „Karte im Web“. Es ist (im Idealfall) das Frontend einer Geodateninfrastruktur, mit standardisierten Diensten, Metadaten, Suche, Berechtigungen und einer nachvollziehbaren Datenherkunft.
Typische Anwendungsfälle in Stadt, Kreis und Verwaltung
In Kommunen tauchen Geoportale in zwei „Betriebsmodi“ auf:
Erstens als Bürger- und Open-Data-Portal (Transparenz, Self-Service, Standortinfos). Dazu zählen zum Beispiel Baustellen- und Verkehrslagen, Radverkehr, Starkregenvorsorgekarten, Bebauungspläne oder Baumkataster-Auszüge, meist als Darstellungsdienst (WMS/WMTS) plus optionaler Download (WFS/Downloadlink).
Zweitens als internes Verwaltungsportal (Fachabteilungen, Außendienst, Krisenstab): Hier zählen zusätzlich Funktionen wie attributbasierte Abfragen (WFS/Feature-Zugriff), fachliche Suchen, Druck, Verknüpfung mit Dokumenten (z. B. Akten/Pläne) oder Rollen- und Rechtemodelle.
Ein praktisches Beispiel für „Portal als zentrale Servicefunktion“ ist das deutschlandweite Geoportal: Es wird als kostenfreies Web-Angebot von Geodateninfrastruktur Deutschland und dem Bundesamt für Kartographie und Geodäsie betrieben und richtet sich sowohl an Fachleute als auch an interessierte Öffentlichkeit.
Die Bausteine eines Geoportals
Daten, Dienste, Metadaten und Suche
Wenn man Geoportale „entmystifiziert“, bestehen sie fast immer aus vier Bausteinen:
- Geodaten (Raster, Vektor, 3D, Dokumente mit Raumbezug)
- Metadaten, die beschreiben, was die Daten sind, wer verantwortlich ist, wie aktuell sie sind und wie sie genutzt werden dürfen
- Geodatendienste, über die Clients die Daten abrufen (z. B. WMS/WFS/WMTS/OGC API)
- Discovery/Suche, die Benutzer überhaupt erst zu den passenden Inhalten führt
Genau diese Logik steckt auch in den rechtlichen und organisatorischen Rahmenwerken rund um INSPIRE und die deutsche Geodateninfrastruktur: Es geht um standardisierte Dienste (Suche, Darstellung, Download, Transformation etc.) und um Metadaten als Voraussetzung, damit Ressourcennachweise überhaupt auffindbar und nutzbar sind.
Eine besonders praxisrelevante Unterscheidung aus dem Alltag der GDI-Umsetzung: In Geodateninfrastrukturen existieren grundsätzlich zwei Typen von „Metadatendokumenten“, (1) Capabilities-Dokumente der Dienste und (2) ISO-Metadaten (z. B. ISO 19115/19119) in Katalogen. Das ist wichtig, weil viele „Geoportal-Probleme“ eigentlich Metadaten- oder Kopplungsprobleme sind.
Merksatz für die Praxis: Ein Geoportal funktioniert dann gut, wenn es für die Nutzer drei Fragen schnell beantwortet: „Was gibt es?“, „Woher kommt es?“ und „Wie kann ich es (rechtskonform) nutzen?“
OGC-Standards verständlich erklärt: WMS, WFS, WMTS, OGC API Features
WMS vs. WFS vs. WMTS
Die meisten kommunalen Geoportale stehen und fallen mit OGC-Standards, also Spezifikationen des Open Geospatial Consortium. Sie sorgen dafür, dass verschiedene Clients (Webviewer, Desktop-GIS, Fachverfahren) interoperabel mit Geodiensten sprechen können. [2]
WMS (Web Map Service) liefert georeferenzierte Kartenbilder (PNG/JPEG etc.). Der Client bekommt also eine gerenderte Karte, nicht „die Rohdaten“, ideal für Hintergrundkarten, thematische Visualisierung, Legenden und berechenbare Performance bei vielen Nutzenden.
WFS (Web Feature Service) liefert Objekte (Features) und Attribute, also Vektordaten auf Feature-Ebene. Das ist der Standard für Abfragen, Selektion, Analyse und (je nach Profil) auch Editier- und Transaktionsoperationen. Gleichzeitig ist WFS „mächtig“, aber dadurch auch anfälliger für Performance- und Größenprobleme, wenn man ihn wie einen WMS behandelt. [3]
WMTS (Web Map Tile Service) liefert vordefinierte Kacheln (Tiles). Dadurch können Karten extrem schnell ausgeliefert werden, weil nicht jeder Request „on-the-fly“ gerendert werden muss. Für hochfrequentierte Basemaps oder Orthofotos ist WMTS oft die bessere Wahl als WMS.
OGC API Features als moderne Alternative
Die OGC API-Familie ist die „modernere“ Generation von Web-Schnittstellen: Statt stark XML- und KVP-geprägter Requests (klassische WxS) setzt sie auf ressourcenorientierte, webtypische Muster (u. a. OpenAPI-Beschreibungen).
OGC API Features ist dabei die zentrale Spezifikation, um Feature-Daten (vergleichbar zu WFS) über moderne Web-Endpunkte bereitzustellen. Der „Core“ ist dabei bewusst minimal und zunächst auf Read-Access beschränkt. [4]
Spannend für die Praxis: Selbst die OGC-WFS-Standardseite weist darauf hin, dass die funktionalen Fähigkeiten heute in einer moderneren Web-API verfügbar sind und Implementierende zur Nutzung von OGC API Features ermutigt werden.
Erklärbox: Wann nehme ich was?
- Wenn Sie „nur anzeigen“ wollen: WMS/WMTS.
- Wenn Sie „Objekte selektieren/abfragen/downloaden“ wollen: WFS oder OGC API Features (modern).
Geodaten-Integration in der Kommune: Von Fachverfahren ins Geoportal
Schnittstellen, Rollen und Datenflüsse
Kommunale IT-Realität heißt fast immer: Daten liegen verteilt, im GIS, im DMS, in Fachverfahren, in Datenbanken, als CAD/PDF, manchmal als Excel. Ein Geoportal wird dann erfolgreich, wenn es als Integrationsschicht gedacht wird: „ein Einstiegspunkt“, aber die Daten bleiben fachlich dort, wo sie gepflegt werden. Das entspricht auch dem GDI-Prinzip der dezentralen Bereitstellung über standardisierte Webservices.
Ein robustes Vorgehen ist, Inhalte pro Thema sauber zu trennen:
- Darstellung (Bürger/integrierte Fachanwendungen) über WMS/WMTS
- Download/Feature-Zugriff (interne Nutzer, Open-Data-Portale, Desktop-GIS) über WFS oder OGC API Features
- Metadaten/Discovery über Katalogfunktionen (z. B. OGC Catalogue Service als Standardkonzept)
Die GDI-Praxis zeigt außerdem: Für OGC API Features existieren andere Metadaten-Mechaniken als bei WxS, weil es kein einzelnes Capabilities-Dokument gibt, Informationen verteilen sich auf Endpunkte wie „Landing Page“ und „collections“.
Metadaten, Lizenzen und Nachnutzung
Für Kommunen ist die Metadatenqualität nicht „nice-to-have“, sondern der Hebel, der aus einem Kartenviewer ein Geoportal macht: Metadaten erklären Zuständigkeit, Aktualität, Nutzungsbedingungen, Raum- und Zeitbezug und bilden die Grundlage für Katalogsuche und Daten-Dienste-Kopplung.
Ein kritischer Punkt ist die Daten-Dienste-Kopplung: Aus Sicht des Dienstes (Capabilities) geschieht sie über MetadataURL-Einträge am jeweiligen Layer, die auf Datensatz-Metadaten verlinken. Genau diese Verknüpfung macht es Portalen möglich, von der Kartenebene zur Datensatzbeschreibung zu springen (und umgekehrt).
Wenn Sie Open-Data-Nutzung ermöglichen wollen, müssen außerdem Nutzungsbedingungen „mitreisen“. In Deutschland sind dafür u. a. die Datenlizenz-Deutschland-Varianten verbreitet; GovData beschreibt z. B. die Einordnung „Namensnennung“ bzw. „Zero“ und deren Wirkungsnähe zu CC-Lizenzen.
Masterportal in der Praxis: WMS/WFS-Layer sauber einbinden
config.json und services.json
Masterportal ist ein webbasierter GIS-Client, der Geodaten anzeigen und (je nach Ausprägung) auch bearbeiten kann. In der aktuellen Dokumentation wird es als Web-GIS beschrieben, basierend auf OpenLayers und Vue.js, entwickelt unter MIT-Lizenz durch eine Gruppe öffentlicher Stellen in Deutschland. [5]
Konzeptionell ist Masterportal für Kommunen interessant, weil es konsequent auf standardisierte Geodienste setzt und konfigurationsgetrieben aufgebaut ist: Die config.json steuert die Portaloberfläche (Menüs, Kartenstart, welche Layer geladen werden etc.) und ist in portalConfig und layerConfig strukturiert.
Die services.json ist die zentrale Stelle, in der Layer- und Serviceinformationen gepflegt werden; die Dokumentation nennt explizit, dass Konfigurationsdetails je nach Servicetyp (u. a. WMS, WFS, SensorThings-API) variieren.
Wenn Sie ohne tiefe Programmierkenntnisse konfigurieren wollen, gibt es zudem mit „Masterportal Admin“ eine webbasierte GUI, um Geoportale auf Basis des Masterportals zu erstellen bzw. Konfigurationen anzupassen.
Mini-Beispiel (stark vereinfacht): WMS- und WFS-Eintrag in services.json
{
"services": [
{
"id": "stadt_wms_bplan",
"type": "WMS",
"url": "https://example-stadt.de/geoserver/wms",
"layers": [
{
"id": "bplan_flaechen",
"name": "bplan:flaechen",
"title": "Bebauungsplan - Flächen",
"visible": false
}
]
},
{
"id": "stadt_wfs_bplan",
"type": "WFS",
"url": "https://example-stadt.de/geoserver/wfs",
"featureTypes": [
{
"id": "bplan_flaechen_ft",
"name": "bplan:flaechen",
"title": "Bebauungsplan - Flächen (Feature-Zugriff)"
}
]
}
]
}Die konkrete Ausprägung (Feldnamen, Optionen, Styling, Suchfunktionen) hängt von Ihrer Masterportal-Version und Ihrem Zielbild ab, entscheidend ist das Prinzip: Darstellung und Feature-Zugriff bewusst trennen und je Dienst typgerecht konfigurieren.
CORS/Proxy, Performance und typische Stolperstellen
Ein Klassiker in kommunalen Umgebungen: Ein Dienst funktioniert im Desktop-GIS, aber nicht im Browser-Geoportal. Häufige Ursache ist CORS (Cross-Origin-Requests). Die Masterportal-Doku benennt das explizit im Proxy-Kontext: GDI-DE empfiehlt, CORS-Header an den benötigten Services zu setzen statt Proxies zu nutzen; die Proxy-Mechanik wird dort als „deprecated“ beschrieben. [5]
Für die Praxis heißt das:
- Bei eigenen Diensten: CORS sauber am Server konfigurieren (kontrolliert, nicht „wildcard“ in sensiblen Szenarien).
- Bei Fremddiensten: prüfen, ob CORS erlaubt ist; andernfalls (nur wenn wirklich nötig) über eine kontrollierte Proxy-Komponente nachdenken, aber mit Blick auf Empfehlung/Deprecation.
Performance-Stolperstelle Nummer 1 ist WFS als „Karte“ zu benutzen. WFS ist für Features gedacht; große Datenmengen ohne Filter/Paginierung führen schnell zu langen Ladezeiten. Der Standard deckt explizit Discovery- und Query-Operationen ab (z. B. GetCapabilities) und ist „feingranular“, das ist Stärke und Risiko zugleich.
Wenn Sie hohe Zugriffszahlen erwarten, ist für Basemaps oder Orthofotos oft WMTS sinnvoll, weil Tiles schneller ausgeliefert werden können.
Praxis-Tipp: Legen Sie in kommunalen Portalen häufig drei Ebenen an: (1) schnelle Basemap via WMTS, (2) Fachlayer via WMS, (3) Objektzugriff/Download via WFS oder OGC API Features.
Best Practices und typische Fehler
Checkliste für kommunale Geoportale
Ein Geoportal „rankt“ (und wird genutzt), wenn es nicht nur technisch läuft, sondern verlässlich ist. Eine kurze Checkliste, die sich aus Standards, GDI-Empfehlungen und typischen Kommunalprojekten ableitet:
- Erstens: Standardkonforme Dienste (WMS/WFS/WMTS/OGC API) sauber dokumentieren und versionieren.
- Zweitens: Metadaten konsequent pflegen (Capabilities + ISO-Metadaten) und Daten-Dienste-Kopplung umsetzen, damit Nutzer von Layer zu Datensatzbeschreibung (Lizenz, Aktualität, Zuständigkeit) gelangen.
- Drittens: Barrierefreiheit mitdenken. Für öffentliche Stellen sind Websites und Apps barrierefrei zu gestalten; auf EU-Ebene ist das in der Richtlinie 2016/2102 geregelt, in Deutschland u. a. über BITV 2.0 umgesetzt, und als harmonisierte Norm wird EN 301 549 herangezogen. [6]
- Viertens: Skalierung: WMTS/Caching für stark frequentierte Inhalte, WMS für Visualisierung, WFS/OGC API für gezielten Objektzugriff (Filter, Begrenzung, sinnvolle Defaults).
Häufige Fehlerbilder (und wie man sie vermeidet)
Der häufigste Fehler ist konzeptionell: „Wir stellen einfach alles als WFS bereit.“ Das endet schnell in langen Ladezeiten oder unbrauchbaren Downloads. Besser ist die klare Rollenverteilung: WMS/WMTS für Visualisierung, WFS/OGC API Features für gezielte Abfragen/Downloads.
Ein weiterer Klassiker ist die fehlende Metadatenkopplung: Layer ohne gepflegte MetadataURL erzeugen ein Portal, das zwar Karten zeigt, aber keine belastbare Datenherkunft, Lizenz und Zuständigkeit kommuniziert. Das schwächt Vertrauen und erschwert auch die interne Governance.
Und schließlich: Browser-Probleme unterschätzen (CORS). Wenn ein Dienst nicht für Cross-Origin-Requests vorbereitet ist, ist das Geoportal für Nutzende „kaputt“, obwohl der Dienst technisch läuft. Die Empfehlung, CORS sauber am Dienst zu setzen, statt dauerhaft auf Proxy-Workarounds zu setzen, ist deshalb in der Masterportal-Doku (mit Bezug auf GDI-DE) klar benannt.