Open Source-Programme finden in unserem täglichen Leben als Privatpersonen immer mehr Verwendung. Aber auch im Umfeld von GIS- und Straßeninformationssystemen wird heutzutage immer öfter auf Open Source-Programmkomponenten zurückgegriffen.

Insofern erscheint es durchaus sinnvoll, sich einmal etwas intensiver mit dem Thema „Open Source“ zu beschäftigen. Dieser Beitrag behandelt den Einsatz von Open Source in komplexen Programmumgebungen bei Straßenbauverwaltungen sowie bei der Erzeugung und Verarbeitung von OKSTRA- und INSPIRE-Daten.

Der Fachvortrag zur Veranstaltung ist im Volltext verfügbar. Das PDF enthält alle Bilder und Formeln.

1 Einleitung

Open Source-Programme finden auch in unserem täglichen Leben als Privatpersonen immer mehr Verwendung. Beispiele dafür sind Office-Werkzeuge wie „Open Office“ oder „Libre Office“, die Bildbearbeitung „GIMP“, die Audiobearbeitung „Audacity“ oder auch (Linux-) Betriebssysteme wie „Ubuntu“.

Aber auch im Umfeld von GIS- und Straßeninformationssystemen wird heutzutage immer öfter auf Open Source-Programmkomponenten zurückgegriffen. Am Beispiel des Informationsmanagements mit der NWSIB bei Straßen.NRW sind das z. B. der Webserver „Tomcat“, der Mapserver „Geoserver“, die Datenbank „PostgreSQL“ („PostGIS“), das Transformationswerkzeug „GeoKettle“ („Pentaho“) oder auch das Desktop-GIS „QGIS“.

Aber wofür steht denn der Begriff „Open Source“ überhaupt? In Wikipedia findet man folgende Definition zu Open Source:

„Als Open Source (aus englisch open source, wörtlich offene Quelle) wird Software bezeichnet, deren Quelltext öffentlich und von Dritten eingesehen, geändert und genutzt werden kann. Open-Source-Software kann meistens kostenlos genutzt werden.“ (Quelle: https://de.wikipedia. org/wiki/Open_Source).

2  Vor- und Nachteile beim Einsatz von Open Source

Ob der Einsatz von Open Source-Software (wirtschaftlich) sinnvoll ist und welche Vor- und Nachteile dieser mit sich bringt, hängt maßgeblich von der Art und Dauer der Verwendung ab.

Hier muss v. a. zwischen projektbezogener Verwendung (z. B. für Datenmigrationen) und dauerhafter Einbindung in produktive Gesamtsysteme unterschieden werden.

Generell können folgende Vorteile für den Einsatz von Open Source angeführt werden:

• Die Programme sind in der Regel sofort online verfügbar.
• Es gibt (zumindest theoretisch) eine hohe Sicherheit, da der Sourcecode offen liegt.
• Es herrscht Transparenz hinsichtlich Art, Umfang, Inhalt und Ort der Datenhaltung.
• Die Software kann selbstständig angepasst und erweitert werden.
• Ein verantwortungsvoller Umgang mit Steuergeldern ist möglich („Public Money? Public Code!“).
• Die Software ist meistens kostenlos.

Ob die Verwendung von Open Source-Software tatsächlich kostenlos ist, hängt vom Einzelfall ab; sie kann kostenlos sein (dies ist auch meistens der Fall), muss es aber nicht. Generell gilt hingegen, dass für Open Source-Software keine Lizenzgebühr erhoben werden darf!

Kosten können jedoch erhoben werden für die Bereitstellung, Implementierung und Integration, Optimierung sowie für Wartung und Support.

Neben den unbestreitbaren Vorteilen kann es allerdings auch eine Reihe von Nachteilen beim Einsatz von Open Source geben:

• Es gibt weder Garantien noch einen klassischen Support.
• Es ist unsicher, ob und wie ein Programm weiterentwickelt wird.
• Zum Teil existieren unübersichtliche Lizenzen unklare Konsequenzen aus den Lizenzmodellen.
• Häufig sind tiefgreifende IT-Kenntnisse für Installation, Konfiguration und Betrieb der Software erforderlich.

Ein Beispiel, das sowohl die Vor- als auch die Nachteile von Open Source verdeutlicht, war das Bekanntwerden einer kritischen Sicherheitslücke in der Open Source-Bibliothek „Log4J“ im Dezember 2021, vor der auch das Bundesamt für Sicherheit in der Informationstechnik (BSI) warnte und hierfür die Warnstufe „rot“ ausrief.

Bei Log4J handelt es sich um eine Programmbibliothek zum Protokollieren („Loggen“) von Softwareereignissen. Diese Bibliothek ist weit verbreitet und wird in fast allen großen Open Source-Projekten eingebunden und verwendet.

Die Sicherheitslücke konnte vor allem dadurch aufgedeckt werden, dass der Programmcode offen liegt und von jedem eingesehen werden kann. Problematisch war jedoch die Tatsache, dass Log4J kein eigenständiges Programm darstellt, sondern als Hilfsbibliothek in diversen Versionen in unterschiedlichsten Projekten verwendet wird.

Insofern waren viele IT-Abteilungen weltweit über den Jahreswechsel damit beschäftigt, herauszufinden, wo und in welchen Programmsystemen diese Bibliothek überhaupt verwendet wird und – falls ja – ob die verwendete Version in der eingesetzten Konfiguration auch wirklich von der Sicherheitslücke betroffen ist.

In einem zweiten Schritt war dann zu klären, ob und wie die Sicherheitslücke geschlossen werden kann. Nicht alle Open Source-Produkte und -Hersteller konnten zeitnah eine eigene Lösung anbieten, und ein einfaches Austauschen der Bibliothek durch eine aktuelle Version war aufgrund von Kompatibilitätsproblemen nicht überall möglich.

Hier wurden also die Nachteile deutlich, dass es bei Open Source-Produkten häufig keine Gewährleistung oder strukturierte Weiterentwicklung gibt und eine schnelle Lösung nur dann herbeigeführt werden konnte, wenn die Unternehmen, in denen von der Sicherheitslücke betroffene Produkte eingesetzt wurden, entweder selbst über die notwendigen IT-Kenntnisse verfügten oder aber auf kompetente Supportpartner zurückgreifen konnten.

Positiv zu vermerken ist hingegen, dass eine Problemlösung trotz der hier aufgeführten Nachteile in den meisten Fällen kurzfristig erfolgen konnte, kein größerer Schaden entstanden ist und das BSI die Warnstufe inzwischen auf „gelb“ herabgesetzt hat.

3 Rechtliche Rahmenbedingungen beim Einsatz von Open Source

3.1 Lizenzbedingungen

Beim Einsatz von Open Source-Software sind auf jeden Fall die Lizenzbedingungen zu beachten. Wird ein Open Source-Produkt lediglich unverändert für spezielle Aufgaben (z. B. eine Datenmigration) verwendet, so ist dies in der Regel unproblematisch. Konsequenzen hingegen könnten sich dann ergeben, wenn Open Source-Komponenten in ein bestehendes umfassenderes Programmsystem integriert werden sollen.

Grundlegend wird bei Open Source zwischen non-permissiven und permissiven Lizenzen unterschieden. Bei einer non-permissiven Lizenz müssen die Nutzer strengere Auflagen beachten, wenn sie den Code weiterentwickeln oder mit anderen kombinieren wollen (Copyleft-Effekt). Hierbei besteht die Pflicht, alle Weiterentwicklungen ebenfalls unter den ursprünglichen Bedingungen zu lizenzieren.

Beispiele für non-permissive Lizenzen sind die General Public License (GPL 2.0, GPL 3.0), die Light GPL (LGLP) oder die GNU Free Documentation License (GFDL).

Bild 1: Unterteilung in permissive und non-permissive (Copyleft-)Lizenzen (Quelle: https://www. whitesourcesoftware.com/resources/blog/open-source-licenses-explained)

Permissive Lizenzen hingegen sind freigiebiger, diese Non-Copyleft-Lizenzen geben den Nutzern mehr Freiheit bei der Verbreitung von Weiterentwicklungen. Entwickler können den Quellcode in neue Produkte einfließen lassen und sogar proprietär (herstellergebunden) lizenzieren. Beispiele hierfür sind die Lizenzen von Apache, BSD oder MIT.

Das Bild 2 zeigt die prozentuale Verteilung der unterschiedlichen Lizenztypen aus dem Jahr 2003. Auch wenn diese Statistik etwas veraltet ist, so gilt nach wie vor, dass die meisten Lizenzen im Open Source-Umfeld non-permissiv und somit eher restriktiv sind.

Bild 2: Verteilung unterschiedlicher Open Source-Lizenzen (Quelle: https://www.berlios.de/open-source-lizenzen)

3.2 Rechtliche Konsequenzen

Wird nun ein Open Source-Produkt mit einer non-permissiven (Copyleft-)Lizenz in ein anderes Produkt integriert, so hat dies unter Umständen rechtliche Auswirkungen auf die Lizenz des Gesamtprodukts.

Ein Beispiel hierfür stellt das Auskunftssystem „NWSIB-online“ bei Straßen.NRW dar. Dieses nutzt das WebGIS-Framework „Osiris“ der Firma GIS Consult sowie als Kartenserver die Open Source-Komponente „Geoserver“ (https://geoserver.org).

Da der Geoserver auf der non-permissiven GPL-Lizenz basiert, stellt sich nun die Frage, ob damit auch das Gesamtprojekt NWSIB-online unter eine non-permissive Open Source Lizenz gestellt werden muss.

Ein Auszug aus der GNU GENERAL PUBLIC LICENSE legt dies zunächst nahe:

„2b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License”.

Allerdings gibt es weitere Passagen in der Lizenz, die diese Aussage zum Teil wieder relativieren: „If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you”.

Dadurch, dass es sich beim Geoserver im Gesamtsystem von NWSIB-online um eine eigenständige, austauschbare Komponente handelt (bis vor kurzer Zeit kam für die Erzeugung der Karten noch ein kommerzielles GIS zum Einsatz), kann die oben genannte Frage also getrost verneint werden: die Verwendung des Geoservers führt in diesem Fall also nicht dazu, dass das Gesamtsystem unter dieselbe Lizenz gestellt werden muss.

Bild 3: Systemarchitektur des Frameworks „GC Osiris“, auf dem NWSIB-online beruht

4 Verwendung von Open Source bei Datenaufbereitungen

Neben der Integration in komplexe Gesamtsysteme dürfte der Hauptanwendungsfall von Open Source-Programmen vielmehr die ad hoc-Verwendung zur Durchführung spezieller Aufgaben sein. Hierzu gehören im Bereich der Straßenbauverwaltung auch die Erzeugung und Bereitstellung von OKSTRA- und INSPIRE-Daten.

Ein Beispiel hierfür ist die Bereitstellung von INSPIRE-Daten für Hessen Mobil, die 2021 fast ausschließlich unter Verwendung von Open Source-Programmen umgesetzt wurde.

4.1 Ausgangssituation

Hessen Mobil hat sich im letzten Jahr entschieden, bis Ende 2023 das Informationsmanagement mit der NWSIB einzuführen; die Erzeugung von OKSTRA-Daten in Hessen erfolgt bereits seit 2020 mit den für die NWSIB entwickelten (Open Source-) Werkzeugen.

Da die Verträge zur Bereitstellung von INSPIRE-Services bei der Hessischen Zentrale für Datenverarbeitung (HZD) ausgelaufen waren, musste kurzfristig eine Alternative gefunden und implementiert werden.

Es sollten also so schnell wie möglich performant über das Internet erreichbare, INSPIRE-konforme Dienste für Hessen Mobil aufgebaut werden. Dazu gehören

• Metadaten zu Daten und Diensten.
• View-Services: Web Map Services zur Darstellung der Daten.
• Download-Services: Download- und Abfragedienste (WFS).

4.2 Softwareauswahl

Für die geplante Aufgabenstellung stehen grundsätzlich eine größere Auswahl sowohl kommerzieller als auch freier Lösungen zur Verfügung.

Der Großteil der Verwaltungen bedient sich der Software „ArcGIS for INSPIRE“. Meistens erfolgt die Bereitstellung der Services bei landeseigenen IT-Zentren und/oder den Vermessungsabteilungen (v. a. die fachliche Betreuung).

Mit „degree“, „GeoNetwork opensource“ (CSW) sowie „Geoserver“ (WMS/WFS) stehen jedoch auch diverse Open Source-Lösungen für die Publizierung von INSPIRE-Diensten zur Verfügung.

Aus wirtschaftlichen Gründen hat Hessen Mobil sich entschieden, die Bereitstellung von INSPIRE-Services auf Basis von Open Source-Produkten zu realisieren.

4.3 Datenkonvertierung und -bereitstellung

Für die Durchführung des Projektes waren eine Reihe einzelner Schritte erforderlich, bei denen jeweils unterschiedliche Open Source-Produkte zum Einsatz kamen.

Schritt 1: Import der Straßendaten in eine PostGIS-Datenbank

In einem ersten Schritt wurden die Straßendaten von Hessen Mobil aus einer Oracle-Datenbank in eine PostGIS-Datenbank (Open Source) mit dem Datenmodell der NWSIB importiert.

Schritt 2: Konvertieren der Straßendaten ins OKSTRA-Datenmodell

Im Schritt zwei erfolgte die Modelltransformation aus den ASB-konformen NWSIB-Daten in eine PostGIS-basierte OKSTRA-Datenbank. Die Erzeugung der OKSTRA-Datenbank übernahm hierbei das OKSTRA-Werkzeug, für die durchaus komplexe Datentransformation wurde das Open Source-ETL-Tool „GeoKettle“ (auf Basis der Community-Edition der Pentaho Data Integration) verwendet.

Bild 4: Workbench des Open Source-ETL-Tools „GeoKettle“

Schritt 3: Transformation OKSTRA -> INSPIRE

Nach der Erzeugung eines OKSTRA-Datenbestandes konnte dieser mit dem OKSTRA-Werkzeug in eine XML-Datei exportiert werden, die wiederum als Eingangsgröße für das von Bund und Ländern finanzierte Tool „O2I“ (OKSTRA to INSPIRE) diente.

Kern des O2I-Tools ist das Open Source-ETL-Tool „Talend”, mit dem die OKSTRA-Daten in das INSPIRE-Format transformiert werden. Als Ergebnis dieses komplexen Prozesses erhält man eine GML-Datei mit den Straßendaten im INSPIRE-Format.

Schritt 4: Aufbau einer Auskunftsdatenbank

Da eine mehrere Gigabyte große GML-Datei schlecht für eine Online-Beauskunftung geeignet ist, mussten die INSPIRE-Daten wieder in eine PostGIS-Datenbank überführt werden. Hierfür bot sich die Open Source-Bibliothek „ogr2ogr“ an, die Bestandteil der GIS-Tools „GDAL“ ist. Mit „ogr2ogr“ ist es möglich, das komplexe GML-File in einem Rutsch in ein PostGIS-Schema zu überführen, dabei alle erforderlichen Tabellen anzulegen und bei Bedarf gleichzeitig eine Koordinatentransformation in ein von INSPIRE vorgeschriebenes Koordinatensystem durchzuführen. Das Bild 5 zeigt das Skript zum Import der INSPIRE-Daten:

Bild 5: Import-Skript mit „ogr2ogr“

Am Ende des Import-Skripts wird dann noch ein Modifikationsskript ausgeführt, das in der Datenbank für einen performanteren Zugriff einige Primary Keys, Indizes und Views anlegt.

Schritt 5: Installation und Konfiguration eines Geoservers

Sowohl die Kartendarstellungen per WMS als auch die Datenabfragen per WFS werden von einem Geoserver übernommen. Dazu wird derzeit im Projekt für Hessen Mobil ein Geoserver in der Version 2.19.2 mit den Plugins für INSPIRE und „Application Schema“ verwendet.

Das INSPIRE-Plugin ist notwendig, um die Capabilities-Dokumente des Geoservers INSPIRE-konform zu gestalten, das Plugin „Application Schema“ hingegen, um die Ausgabe komplexer XML-Objekte zu ermöglichen.

Für die Konfiguration des WFS-Applikationsschemas, also die Zuordnung von Tabellen und Attributen zu Elementen des INSPIRE-GML-Schemas, wurde das Open Source-ETL-Tool Hale Studio (https://www.wetransform.to) verwendet, zu dem ein spezielles Geoserver-Plugin existiert.

Bild 6: Konfiguration des WFS-Applikationsschemas mit HALE

Die von Hale erzeugten Mapping-Konfigurationen mussten allerdings noch einmal manuell überarbeitet und erweitert werden, um eine hundertprozentige Konformität zum INSPIRE-GML-Schema zu erhalten. Mit dieser Konfiguration konnten dann die Layer und FeatureTypes im Geoserver erzeugt und veröffentlicht werden.

Schritt 6: Bereitstellung von Metadaten

Neben der Bereitstellung von Darstellungsdiensten (WMS) und Download-Services (WFS) ist auch eine Bereitstellung von INSPIRE-konformen Metadaten erforderlich. Hierfür wurde das Open Source-Produkt „GeoNetwork opensource“ (https://geonetwork-opensource.org) installiert und von Hand konfiguriert.

Schritt 7: Validierung der Daten und Services

Um sicherzustellen, dass sowohl die Daten als auch die formalen Antwortdokumente der Services den Anforderungen von INSPIRE genügen, wurden diese bereits während der einzelnen Bearbeitungsschritte ständig überprüft und validiert.

Dazu wurden primär die Testsuite der GDI-DE (https://testsuite.gdi-de.org) sowie der ETF-Validator (https://inspire.ec.europa.eu/validator/home/index.html) verwendet.

Bild 7: Validierung der Daten und Services

Schritt 8: Veröffentlichung der Services

In einem letzten Schritt wurden dann die INSPIRE-Services und -Daten im Internet unter der Adresse https://sibhessen.de veröffentlicht.

Folgende Programme wurden dafür installiert und konfiguriert:

• PostgreSQL-Datenbank (Version 12) mit PostGIS-Erweiterung (Version 1.1).
• Apache HTTP-Server (Version 4) als Reverse Proxy.
• Apache Tomcat 9 als Applikationsserver (basierend auf Java8).
• Webapplikation GeoNetwork Opensource für die Bereitstellung von Metadaten.
• Webapplikation Geoserver für die Karten- und Datendienste.

Bild 8: Veröffentlichung der Daten unter https://sibhessen.de

4.4 Erfahrungen bei der Umsetzung

Es ist in sehr kurzer Zeit gelungen, INSPIRE-konforme Daten und Dienste für Hessen Mobil zu erzeugen, zu validieren und zu publizieren.

Dabei wurde ausschließlich auf Open Source-Produkte und -Werkzeuge zurückgegriffen.

Für eine erfolgreiche Validierung der Dienste mussten jedoch manuell komplexe Konfigurationsdateien nachbearbeitet sowie einige Programmänderungen am Geoserver vorgenommen werden, eine Installation „out of the box“ reichte nicht aus.

Insofern war die Umsetzung nur mit einem Team möglich, das tiefgehende Kenntnisse sowohl in den Datenmodellen und Vorgaben von OKSTRA und INSPIRE als auch den technischen Werkzeugen besaß.