fossgis2020

Vektortiles haben das Potential, die bewährten Rasterkarten in vielen Bereichen abzulösen oder mindestens massgeblich zu ergänzen. Dieser Vortrag zeigt, wie Vektortiles generiert werden können und was dabei zu beachten ist. Weitere Themen sind das Styling der Karten mit Mapbox GL JSON und die Publikation mit OpenLayers 6 und Mapbox GL JS. Vektortiles haben das Potential, die bewährten Rasterkarten in vielen Bereichen abzulösen oder mindestens massgeblich zu ergänzen. Dieser Vortrag zeigt, wie Vektortiles generiert werden können und was dabei zu beachten ist. Weitere Themen sind das Styling der Karten mit Mapbox GL JSON und die Publikation mit OpenLayers 6 und Mapbox GL JS. about this event: https://pretalx.com/fossgis2020/talk/7EPGZD/

Das Project [MAnnheimer MAPAthons](https://mamapa.org) ("MAMAPA") organisiert seit Anfang 2018 Mapathons unter gemeinsamer Beteiligung von neu Zugewanderten und "Einheimischen". Durch das Kartografieren im Tandem wird über die humanitäre Hilfe hinaus ein konkreter Beitrag zur Integration geleistet. Das Projekt wird sowohl von lokalen Integrationsträgern und Behörden als auch von [CartONG](https://cartong.org), France und Mitgliedern des Geografischen Instituts der Uni Heidelberg unterstützt. Mit dem Ziel weitere Projekte dieser Art in Deutschland -- oder anderswo -- anzuregen, wird die Präsentation vor allem beschreiben, was überhaupt gemacht wird, wie alles organisiert ist und wie die Teilnehmenden es beurteilen. Bis Ende 2019 wurden 20 Mapathons veranstaltet. U.a. hat dieser Erfolg dazu geführt, dass CartONG ein sehr ähnliches Projekt 2018-2019 in Frankreich durchführte. Momentan wird über einen Antrag zur Erweiterung der Projektidee auf europäischer Ebene diskutiert. about this event: https://pretalx.com/fossgis2020/talk/PWE3PX/

Das Project [MAnnheimer MAPAthons](https://mamapa.org) ("MAMAPA") organisiert seit Anfang 2018 Mapathons unter gemeinsamer Beteiligung von neu Zugewanderten und "Einheimischen". Durch das Kartografieren im Tandem wird über die humanitäre Hilfe hinaus ein konkreter Beitrag zur Integration geleistet. Das Projekt wird sowohl von lokalen Integrationsträgern und Behörden als auch von [CartONG](https://cartong.org), France und Mitgliedern des Geografischen Instituts der Uni Heidelberg unterstützt. Mit dem Ziel weitere Projekte dieser Art in Deutschland -- oder anderswo -- anzuregen, wird die Präsentation vor allem beschreiben, was überhaupt gemacht wird, wie alles organisiert ist und wie die Teilnehmenden es beurteilen. Bis Ende 2019 wurden 20 Mapathons veranstaltet. U.a. hat dieser Erfolg dazu geführt, dass CartONG ein sehr ähnliches Projekt 2018-2019 in Frankreich durchführte. Momentan wird über einen Antrag zur Erweiterung der Projektidee auf europäischer Ebene diskutiert. about this event: https://pretalx.com/fossgis2020/talk/PWE3PX/

Vektortiles haben das Potential, die bewährten Rasterkarten in vielen Bereichen abzulösen oder mindestens massgeblich zu ergänzen. Dieser Vortrag zeigt, wie Vektortiles generiert werden können und was dabei zu beachten ist. Weitere Themen sind das Styling der Karten mit Mapbox GL JSON und die Publikation mit OpenLayers 6 und Mapbox GL JS. Vektortiles haben das Potential, die bewährten Rasterkarten in vielen Bereichen abzulösen oder mindestens massgeblich zu ergänzen. Dieser Vortrag zeigt, wie Vektortiles generiert werden können und was dabei zu beachten ist. Weitere Themen sind das Styling der Karten mit Mapbox GL JSON und die Publikation mit OpenLayers 6 und Mapbox GL JS. about this event: https://pretalx.com/fossgis2020/talk/7EPGZD/

Das radiologische Notfall-Informationssystem des Bundes (IMIS3) hat Ende 2019 das vorhergehende proprietäre System abgelöst. IMIS3 wurde dabei konsequent aus freien Komponenten aufgebaut und um räumliche Funktionen erweitert. Aufbau und Zusammenspiel der Komponenten des IMIS3, sowie die Umsetzung der mit der Entwicklung einhergehenden Open-Source-Strategie in einer Behörde des Bundes werden ebenso dargestellt, wie der Impact der Entwicklungen auf bestehenden Projekte aus dem Umfeld des FOSSGIS. Zu den Aufgabenbereichen des Bundesamtes für Strahlenschutz (BfS) gehört es, bei einem radiologischen Notfall, eigene und anderweitig verfügbare relevante Daten zu sammeln und zu erfassen, zu verarbeiten und zu bewerten sowie Dokumente zu erstellen, die die notwendigen Informationen enthalten, um den Krisenstab zu befähigen, über geeignete Maßnahmen des Notfallschutzes zu entscheiden. Der dabei eingesetzte Softwarestack wird unter der Bezeichnung IMIS (integriertes Mess- und Informationssystem) betrieben. Nach mehreren Jahren Entwicklungszeit wurde das bisherige proprietäre System (IMIS2) durch ein konsequent auf freien Komponenten und mit deutlicher Erweiterung um räumliche Funktionen und jetzt web-basierendes System ersetzt. Das neue IMIS3 wird von nun an bei der Bewältigung radiologischer Ereignisse und Notfälle vom radiologischen Lagezentrum des Bundes eingesetzt. Die bei der Neuentwicklung des IMIS3 konsequent eingesetzte Open-Source-Strategie kombiniert mehrere OSGeo-Projekte und hat einerseits einigen Input in diese Projekte geliefert und andererseits weitere Projekte neu entstehen lassen, die vom BfS unter der GPL auf github.com veröffentlicht wurden. Diese offensive Vorgehensweise ist für ein Bundesamt wohl eher ungewöhnlich. Im Vortrag wird die Architektur des IMIS3 im Bezug auf die verwendeten Open-Source-GIS-Komponenten dargestellt. Diese enthält zum einen den aus OpenLayers und GeoExt aufgebauten generischen Web-GIS-Klienten des BfS. Aussehen, Inhalt und Funktionalität des Web-GIS wird über ein eigenes in Geonetwork OS gepflegtes Metadatenschema gesteuert. Die Generik des Klienten erlaubt es diesen auch für andere Fachbereiche mit vergleichbaren Datenstrukturen abseits des radiologischen Notfallschutzes einzusetzen. Die Machbarkeit einer solchen universellen Verwendung wird im WS 2019/2020 im Rahmen eines Studierendenprojekts an der Hochschule Karlsruhe geprüft und dessen Ergebnisse und Erfahrungen im Vortrag mit eingebaut. Zudem kommen bei IMIS3 noch PostGIS, Geostyler, Mapfish Print sowie diverse andere Projekte zum Einsatz, die das Gesamtsystem zur Bewältigung radiologischer Notfälle befähigt. about this event: https://pretalx.com/fossgis2020/talk/YFEKKC/

Das radiologische Notfall-Informationssystem des Bundes (IMIS3) hat Ende 2019 das vorhergehende proprietäre System abgelöst. IMIS3 wurde dabei konsequent aus freien Komponenten aufgebaut und um räumliche Funktionen erweitert. Aufbau und Zusammenspiel der Komponenten des IMIS3, sowie die Umsetzung der mit der Entwicklung einhergehenden Open-Source-Strategie in einer Behörde des Bundes werden ebenso dargestellt, wie der Impact der Entwicklungen auf bestehenden Projekte aus dem Umfeld des FOSSGIS. Zu den Aufgabenbereichen des Bundesamtes für Strahlenschutz (BfS) gehört es, bei einem radiologischen Notfall, eigene und anderweitig verfügbare relevante Daten zu sammeln und zu erfassen, zu verarbeiten und zu bewerten sowie Dokumente zu erstellen, die die notwendigen Informationen enthalten, um den Krisenstab zu befähigen, über geeignete Maßnahmen des Notfallschutzes zu entscheiden. Der dabei eingesetzte Softwarestack wird unter der Bezeichnung IMIS (integriertes Mess- und Informationssystem) betrieben. Nach mehreren Jahren Entwicklungszeit wurde das bisherige proprietäre System (IMIS2) durch ein konsequent auf freien Komponenten und mit deutlicher Erweiterung um räumliche Funktionen und jetzt web-basierendes System ersetzt. Das neue IMIS3 wird von nun an bei der Bewältigung radiologischer Ereignisse und Notfälle vom radiologischen Lagezentrum des Bundes eingesetzt. Die bei der Neuentwicklung des IMIS3 konsequent eingesetzte Open-Source-Strategie kombiniert mehrere OSGeo-Projekte und hat einerseits einigen Input in diese Projekte geliefert und andererseits weitere Projekte neu entstehen lassen, die vom BfS unter der GPL auf github.com veröffentlicht wurden. Diese offensive Vorgehensweise ist für ein Bundesamt wohl eher ungewöhnlich. Im Vortrag wird die Architektur des IMIS3 im Bezug auf die verwendeten Open-Source-GIS-Komponenten dargestellt. Diese enthält zum einen den aus OpenLayers und GeoExt aufgebauten generischen Web-GIS-Klienten des BfS. Aussehen, Inhalt und Funktionalität des Web-GIS wird über ein eigenes in Geonetwork OS gepflegtes Metadatenschema gesteuert. Die Generik des Klienten erlaubt es diesen auch für andere Fachbereiche mit vergleichbaren Datenstrukturen abseits des radiologischen Notfallschutzes einzusetzen. Die Machbarkeit einer solchen universellen Verwendung wird im WS 2019/2020 im Rahmen eines Studierendenprojekts an der Hochschule Karlsruhe geprüft und dessen Ergebnisse und Erfahrungen im Vortrag mit eingebaut. Zudem kommen bei IMIS3 noch PostGIS, Geostyler, Mapfish Print sowie diverse andere Projekte zum Einsatz, die das Gesamtsystem zur Bewältigung radiologischer Notfälle befähigt. about this event: https://pretalx.com/fossgis2020/talk/YFEKKC/

Vorstellung einer Open Source Service Registry für Geodatendienste, welche sich zur Zeit in der Entwicklung durch die GDI-RP befindet. Das System schließt an alte Tugenden bestehender Geodateninfrastrukturen an und bietet darüber hinaus Funktionen, welche den Anforderungen von modernen Webapplikationen entsprechen. Als Herzstück einer jeden Geodateninfrastruktur sollte eine Service Registry - eine „Diensteregistrierungskomponente“ - stehen. Die Anforderungen an eine solche Registrierungskomponente sind vielfältig und mitunter aufgrund komplexer technischer Zusammenhänge nicht im Handumdrehen umzusetzen. Hierzu zählen u.a. die Registrierung von Web Map Services oder Web Feature Services in den jeweiligen technischen Standard, die Zugänglichkeit dieser für Außenstehende, Anforderungen an die Zugriffsbeschränkung ausgewählter Dienste oder einzelner Subelemente wie bspw. Layer, eine Gruppen- und Nutzerverwaltung, usw. „Mr. Map“ wird seit April 2019 von der GDI-RP, mit Sitz in Koblenz, konzipiert und entwickelt und stellt eine Lösung für die technischen Anforderungen und Erwartungen des modernen Benutzers dar. Als Webapplikation läuft „Mr. Map“ plattformübergreifend und bietet bereits, neben den eingangs gelisteten Grundfunktionen einer Service Registry, zusätzliche Komponenten, wie bspw. eine Suchschnittstelle zur Anbindung an weitere Systeme wie Geoportale usw., ein internes Publisher-System zur Verteilung der Registrierungsrechte eigener Dienste auf andere Nutzer oder einen integrierten Metadateneditor, mit welchem nicht-technische Metadaten eines Dienstes bearbeitet werden können. Im Vortrag werden die Motivation des Projektes, die Leitsätze der Entwicklung und des Designs und einige technische Hintergründe beleuchtet sowie Inhalte des bisherigen Entwicklungsstandes präsentiert. about this event: https://pretalx.com/fossgis2020/talk/K7VNXP/

Auf Basis digitaler Bahnhofspläne wird ein Kartendienst mit Fußgängerrouting bereitgestellt, der die Orientierung und die Navigation im Bahnhof erleichtert. Die Einheit Reisendeninformation der Deutschen Bahn AG hat zur Aufgabe, Lösungen zu entwickeln, die den Reisendenkomfort erhöhen. Im Rahmen dieses Auftrags soll Reisenden die Orientierung im Bahnhof vereinfacht werden. Über digitale Bahnhofspläne soll ein Fußgängerrouting, das Reisenden im Bahnhof die Navigation zu bestimmten POI's (Geschäften, Geldautomaten, u.v.m.) erlaubt, angeboten werden. Das Routing selber wird über die PostgreSQL-Erweiterung PG-Routing auf einem Routingnetz gerechnet. Als Grundlage dienen dabei eigene Bahnhofspläne, die mit Daten aus OpenStreetMap ergänzt wurden. Anschlusspunkte außerhalb des Bahnhofs sollen über das OSM-Strassennetz verbunden werden. Weiterhin wurden nicht-begehbare Flächen wie Infotafeln, Schächte (u.a.) sowie Rolltreppen, Treppen und Aufzüge für Übergänge zu den unterschiedlichen Ebenen bei der Erstellung des Routingnetzes berücksichtigt. Das Routingnetz wurde in verschiedenen Dichten mit GRASS GIS erzeugt und in die Datenbank importiert. Der Vortrag stellt die gesamte, auf einem Open Source Stack basierende Lösung, sowie auch die Integration der OSM Daten vor. about this event: https://pretalx.com/fossgis2020/talk/UDVAAL/

Auf Basis digitaler Bahnhofspläne wird ein Kartendienst mit Fußgängerrouting bereitgestellt, der die Orientierung und die Navigation im Bahnhof erleichtert. Die Einheit Reisendeninformation der Deutschen Bahn AG hat zur Aufgabe, Lösungen zu entwickeln, die den Reisendenkomfort erhöhen. Im Rahmen dieses Auftrags soll Reisenden die Orientierung im Bahnhof vereinfacht werden. Über digitale Bahnhofspläne soll ein Fußgängerrouting, das Reisenden im Bahnhof die Navigation zu bestimmten POI's (Geschäften, Geldautomaten, u.v.m.) erlaubt, angeboten werden. Das Routing selber wird über die PostgreSQL-Erweiterung PG-Routing auf einem Routingnetz gerechnet. Als Grundlage dienen dabei eigene Bahnhofspläne, die mit Daten aus OpenStreetMap ergänzt wurden. Anschlusspunkte außerhalb des Bahnhofs sollen über das OSM-Strassennetz verbunden werden. Weiterhin wurden nicht-begehbare Flächen wie Infotafeln, Schächte (u.a.) sowie Rolltreppen, Treppen und Aufzüge für Übergänge zu den unterschiedlichen Ebenen bei der Erstellung des Routingnetzes berücksichtigt. Das Routingnetz wurde in verschiedenen Dichten mit GRASS GIS erzeugt und in die Datenbank importiert. Der Vortrag stellt die gesamte, auf einem Open Source Stack basierende Lösung, sowie auch die Integration der OSM Daten vor. about this event: https://pretalx.com/fossgis2020/talk/UDVAAL/

Vorstellung einer Open Source Service Registry für Geodatendienste, welche sich zur Zeit in der Entwicklung durch die GDI-RP befindet. Das System schließt an alte Tugenden bestehender Geodateninfrastrukturen an und bietet darüber hinaus Funktionen, welche den Anforderungen von modernen Webapplikationen entsprechen. Als Herzstück einer jeden Geodateninfrastruktur sollte eine Service Registry - eine „Diensteregistrierungskomponente“ - stehen. Die Anforderungen an eine solche Registrierungskomponente sind vielfältig und mitunter aufgrund komplexer technischer Zusammenhänge nicht im Handumdrehen umzusetzen. Hierzu zählen u.a. die Registrierung von Web Map Services oder Web Feature Services in den jeweiligen technischen Standard, die Zugänglichkeit dieser für Außenstehende, Anforderungen an die Zugriffsbeschränkung ausgewählter Dienste oder einzelner Subelemente wie bspw. Layer, eine Gruppen- und Nutzerverwaltung, usw. „Mr. Map“ wird seit April 2019 von der GDI-RP, mit Sitz in Koblenz, konzipiert und entwickelt und stellt eine Lösung für die technischen Anforderungen und Erwartungen des modernen Benutzers dar. Als Webapplikation läuft „Mr. Map“ plattformübergreifend und bietet bereits, neben den eingangs gelisteten Grundfunktionen einer Service Registry, zusätzliche Komponenten, wie bspw. eine Suchschnittstelle zur Anbindung an weitere Systeme wie Geoportale usw., ein internes Publisher-System zur Verteilung der Registrierungsrechte eigener Dienste auf andere Nutzer oder einen integrierten Metadateneditor, mit welchem nicht-technische Metadaten eines Dienstes bearbeitet werden können. Im Vortrag werden die Motivation des Projektes, die Leitsätze der Entwicklung und des Designs und einige technische Hintergründe beleuchtet sowie Inhalte des bisherigen Entwicklungsstandes präsentiert. about this event: https://pretalx.com/fossgis2020/talk/K7VNXP/

Die Digitalisierung fordert die Verfügbarkeit jeglicher staatlichen Dienstleistung über digitale Kanäle. Geodatenhaltende Stellen müssen dazu eine vergleichsweise große Datenmenge verarbeiten. Monolithische Altverfahren sind aufgrund mangelnder Zuverlässigkeit, Flexibilität und Skalierbarkeit nahezu ungeeignet, diesen Anforderungen adäquat zu begegnen. Vorgestellt wird, wie durch moderne Architekturen und Technologien des Cloud Computing Geodaten effizient verarbeitet werden können. Mit Kubernetes wird eine containerbasierte Plattform aufgesetzt, die horizontale Skalierung der zugrundeliegenden Rechenkapazität und bereitgestellten Applikationen ermöglicht. Für den Anwendungsfall geeignete Applikationen sind OpenFaaS und Minio. OpenFaaS ermöglicht die hoch-skalierbare Verarbeitung in unterschiedlichen Programmiersprachen. Ein- und Ausgabedaten werden für Write-Once-Read-Many Zugriffe optimiert im ObjectStore Minio gespeichert. Am Beispiel des Kampfmittelbeseitigungsdienstes Niedersachsen werden Szenarien für die Transformation und Analyse von historischen Kriegsluftbildern auf dieser Plattform dargestellt und insbesondere die Vorteile der Speicherung von Rasterdaten im Format cloud-optimized GeoTIFF in diesem Kontext aufgezeigt. about this event: https://pretalx.com/fossgis2020/talk/7MSDDM/

Im Projekt OPENER haben wir eine Open Source Applikation zur Erfassung von Informationen zu Barrieren an Haltestellen im ÖPNV entwickelt, welche eine Crowd-basierte flächendeckende und lückenlose Erfassung ermöglicht. Die aktuell in einer separaten Datenbank erfassten Daten sollen ins OSM zurückgespeist werden, wobei der Beitrag die Applikation präsentiert sowie rechtliche und technische Aspekte zur Diskussion stellt. # Einleitung und Hintergrund Barrierefreiheit im öffentlichen Personennahverkehr (ÖPNV) — dies ist ein richtungsweisendes Ziel, das sich die Bundesrepublik Deutschland bis Anfang 2022 mit der Novellierung des Personenbeförderungsgesetzes gesetzt hat. Daraufhin wurden konkrete Anforderungen zur Datenerfassung im Rahmen des Projekts [DELFI+]( https://www.delfi.de/) entwickelt und den Arbeitsgruppen der regionalen, öffentlichen Verkehrsverbünde zur Umsetzung übermittelt. Insbesondere für kleine, in ländlichen Regionen agierende ÖPNV-Verbünde stellt die flächendeckende und lückenlose Erfassung von Haltestelleninformationen zur Barrierefreiheit mit den detaillierten Anforderungen allerdings eine nicht zu bewältigende finanzielle und personelle Herausforderung dar. Allein für Haltestellen sind dies über 48 zu erfassende Attribute pro Haltestellensteig. So hat beispielsweise der Verkehrsverbund Mittelsachsen mit ca. 9.000 Haltestellensteigen insgesamt 432.000 Datensätze zu erheben und zu pflegen! Zu den 48 Steigattributen kommen außerdem noch weitere 39 für die Erfassung von Wegen in und durch die Haltestelle hinzu. Schon diese Zahlen verdeutlichen die Brisanz, die mit dem Thema Datenerhebung verbunden ist. # Projektziel Die Idee im Projekt OPENER ist es, Bürgerinnen und Bürger die Möglichkeit zu geben, sich bei der Datenerfassung zu beteiligen und somit „ihren Nahverkehr“ selbst mit zu verbessern. Das technische Ziel unseres Projektes ist daher die Entwicklung und Bereitstellung einer Open-Data-Plattform zur DELFI+-konformen Erfassung, Bereitstellung und Bewertung von Daten zu Barrieren an Haltestellen des ÖPNV. Die erhobenen Daten dienen daraufhin zur Generierung baulicher Hilfestellungen mit dem Ziel der Erreichung von Barrierefreiheit. Im Projekt wird ein Erfassungswerkzeug entwickelt, das ohne aufwendige Mess- und Eingabeverfahren das Aufnehmen der Daten direkt an der Haltestelle ermöglicht. Ein offener Zugang zu Daten und Software soll daraufhin die Basis für neue Anwendungen sowie für Handlungsempfehlungen für Nutzer, Kommunen und Verkehrsverbünde sein. # Vortragsinhalte ## Entwickelte Plattform Es wurde eine Android-Applikation entwickelt, welche Haltestellensteige in OSM-Karten rendert und für jeden Steig die zu erfassenden DELFI-Attribute in Form von Frage-Dialogen an den Nutzer der App abbildet. Neben Entscheidungsfragen oder Fragen mit Texteingabe als Antwort beinhaltet der DELFI-Katalog Fragen zu Abmaßen, beispielsweise von Bahnsteighöhen oder Wegbreiten. Hierfür wurde in die App ein Vermessungswerkzeug basierend auf Google ARCore entwickelt, das eine unkomplizierte Vermessung dieser Objekte auch ohne Zollstock erlaubt. Die Android-Applikation ist als Open Source im [OPENER App-Repository](https://gitlab.hrz.tu-chemnitz.de/opener/opener-app/) verfügbar. Aktuell wird eine Serveranwendung umgesetzt, sodass die erfassten Daten in einer Datenbank hinterlegt werden können. Dabei existiert für jeden Haltestellensteig eine weltweit eindeutige Identifikationsnummer, die sog. Deutsche Haltestellenidentifikationsnummer (DHID), welche aus dem Zentralen Haltestellenverzeichnis (ZHV) des DELFI e.V. in die Serveranwendung eingespeist wird. Zu Projektende wird im Februar 2020 eine Applikation mit Serveranbindung vorliegen, welche eine ortbezogene Erhebung und Speicherung von Daten an Haltestellen ermöglicht. Nun liegt es nahe, die von den Nutzern erhobenen Daten in OpenStreetMap zurückzuspielen. An dieser Stelle möchten wir sowohl rechtliche als auch technische Aspekte präsentieren und zur Diskussion stellen. ## Rechtliche Aspekte Die bestehenden Daten aus dem ZHV des DELFI e.V. werden durch die Nutzung der OPENER-App veredelt. Konkret heißt dies, dass die vorhandene DHID mit ihren Steig-Koordinaten um die erfassten DELFI-Attribute angereichert werden. Bei der Rückspeisung ins OSM muss also die Lizenzkompatibilität sichergestellt werden. Wir befinden uns aktuell in Absprache mit dem DELFI e.V. über eine Überführung der erhobenen Daten in die Hoheit des Vereins. Bei diesem Schritt streben wir an, die erhobenen Daten unter eine ODbL-kompatible-Lizenz zu stellen. ## Technische Aspekte Für die erhobenen DELFI-Attribute haben wir sinnvolle äquivalente OSM-Tags recherchiert und im [OPENER OSM Wiki](https://wiki.openstreetmap.org/wiki/User:OPENER/DELFI_OSM_Tags) die Zuordnung bestehender Tags zu den DELFI-Attributen aufgelistet. Des Weiteren existiert in OSM bereits eine international eindeutige Nummer zur Referenzierung von ÖPNV-Haltestellen: die IFOPT (Identification of Fixed Objects in Public Transport). Die flächendeckende Datenerhebung hinsichtlich Barrierefreiheit an Haltestellen könnte also unter Verwendung der IFOPT zusammen mit den vorgeschlagenen, äquivalenten Tags erfolgen, indem fehlende Informationen in OSM um die mittels der App erhobenen Daten ergänzt wird. Diese Daten können aus der OPENER-Datenbank extrahiert und in die OSM-Datenbank importiert werden. Dazu werden im Vortrag Import-Konzepte präsentiert und zur Diskussion gestellt. # Referenzen [OPENER Projekt-Webseite](https://www.bmvi.de/SharedDocs/DE/Artikel/DG/mfund-projekte/opener.html) [OPENER App-Repository](https://gitlab.hrz.tu-chemnitz.de/opener/opener-app/) [OPENER OSM Wiki](https://wiki.openstreetmap.org/wiki/User:OPENER/DELFI_OSM_Tags) [IFOPT Wiki-Eintrag]( https://wiki.openstreetmap.org/wiki/DE:Key:ref:IFOPT) # Acknowledgements Das Projekt „OPENER“ startete im März 2019 und wird im Rahmen der Förderrichtlinie „Modernitätsfonds“ (mFUND) mit insgesamt 97.110 Euro durch das Bundesministerium für Verkehr und digitale Infrastruktur (BMVI) gefördert. about this event: https://pretalx.com/fossgis2020/talk/3F8JCB/

Im Projekt OPENER haben wir eine Open Source Applikation zur Erfassung von Informationen zu Barrieren an Haltestellen im ÖPNV entwickelt, welche eine Crowd-basierte flächendeckende und lückenlose Erfassung ermöglicht. Die aktuell in einer separaten Datenbank erfassten Daten sollen ins OSM zurückgespeist werden, wobei der Beitrag die Applikation präsentiert sowie rechtliche und technische Aspekte zur Diskussion stellt. # Einleitung und Hintergrund Barrierefreiheit im öffentlichen Personennahverkehr (ÖPNV) — dies ist ein richtungsweisendes Ziel, das sich die Bundesrepublik Deutschland bis Anfang 2022 mit der Novellierung des Personenbeförderungsgesetzes gesetzt hat. Daraufhin wurden konkrete Anforderungen zur Datenerfassung im Rahmen des Projekts [DELFI+]( https://www.delfi.de/) entwickelt und den Arbeitsgruppen der regionalen, öffentlichen Verkehrsverbünde zur Umsetzung übermittelt. Insbesondere für kleine, in ländlichen Regionen agierende ÖPNV-Verbünde stellt die flächendeckende und lückenlose Erfassung von Haltestelleninformationen zur Barrierefreiheit mit den detaillierten Anforderungen allerdings eine nicht zu bewältigende finanzielle und personelle Herausforderung dar. Allein für Haltestellen sind dies über 48 zu erfassende Attribute pro Haltestellensteig. So hat beispielsweise der Verkehrsverbund Mittelsachsen mit ca. 9.000 Haltestellensteigen insgesamt 432.000 Datensätze zu erheben und zu pflegen! Zu den 48 Steigattributen kommen außerdem noch weitere 39 für die Erfassung von Wegen in und durch die Haltestelle hinzu. Schon diese Zahlen verdeutlichen die Brisanz, die mit dem Thema Datenerhebung verbunden ist. # Projektziel Die Idee im Projekt OPENER ist es, Bürgerinnen und Bürger die Möglichkeit zu geben, sich bei der Datenerfassung zu beteiligen und somit „ihren Nahverkehr“ selbst mit zu verbessern. Das technische Ziel unseres Projektes ist daher die Entwicklung und Bereitstellung einer Open-Data-Plattform zur DELFI+-konformen Erfassung, Bereitstellung und Bewertung von Daten zu Barrieren an Haltestellen des ÖPNV. Die erhobenen Daten dienen daraufhin zur Generierung baulicher Hilfestellungen mit dem Ziel der Erreichung von Barrierefreiheit. Im Projekt wird ein Erfassungswerkzeug entwickelt, das ohne aufwendige Mess- und Eingabeverfahren das Aufnehmen der Daten direkt an der Haltestelle ermöglicht. Ein offener Zugang zu Daten und Software soll daraufhin die Basis für neue Anwendungen sowie für Handlungsempfehlungen für Nutzer, Kommunen und Verkehrsverbünde sein. # Vortragsinhalte ## Entwickelte Plattform Es wurde eine Android-Applikation entwickelt, welche Haltestellensteige in OSM-Karten rendert und für jeden Steig die zu erfassenden DELFI-Attribute in Form von Frage-Dialogen an den Nutzer der App abbildet. Neben Entscheidungsfragen oder Fragen mit Texteingabe als Antwort beinhaltet der DELFI-Katalog Fragen zu Abmaßen, beispielsweise von Bahnsteighöhen oder Wegbreiten. Hierfür wurde in die App ein Vermessungswerkzeug basierend auf Google ARCore entwickelt, das eine unkomplizierte Vermessung dieser Objekte auch ohne Zollstock erlaubt. Die Android-Applikation ist als Open Source im [OPENER App-Repository](https://gitlab.hrz.tu-chemnitz.de/opener/opener-app/) verfügbar. Aktuell wird eine Serveranwendung umgesetzt, sodass die erfassten Daten in einer Datenbank hinterlegt werden können. Dabei existiert für jeden Haltestellensteig eine weltweit eindeutige Identifikationsnummer, die sog. Deutsche Haltestellenidentifikationsnummer (DHID), welche aus dem Zentralen Haltestellenverzeichnis (ZHV) des DELFI e.V. in die Serveranwendung eingespeist wird. Zu Projektende wird im Februar 2020 eine Applikation mit Serveranbindung vorliegen, welche eine ortbezogene Erhebung und Speicherung von Daten an Haltestellen ermöglicht. Nun liegt es nahe, die von den Nutzern erhobenen Daten in OpenStreetMap zurückzuspielen. An dieser Stelle möchten wir sowohl rechtliche als auch technische Aspekte präsentieren und zur Diskussion stellen. ## Rechtliche Aspekte Die bestehenden Daten aus dem ZHV des DELFI e.V. werden durch die Nutzung der OPENER-App veredelt. Konkret heißt dies, dass die vorhandene DHID mit ihren Steig-Koordinaten um die erfassten DELFI-Attribute angereichert werden. Bei der Rückspeisung ins OSM muss also die Lizenzkompatibilität sichergestellt werden. Wir befinden uns aktuell in Absprache mit dem DELFI e.V. über eine Überführung der erhobenen Daten in die Hoheit des Vereins. Bei diesem Schritt streben wir an, die erhobenen Daten unter eine ODbL-kompatible-Lizenz zu stellen. ## Technische Aspekte Für die erhobenen DELFI-Attribute haben wir sinnvolle äquivalente OSM-Tags recherchiert und im [OPENER OSM Wiki](https://wiki.openstreetmap.org/wiki/User:OPENER/DELFI_OSM_Tags) die Zuordnung bestehender Tags zu den DELFI-Attributen aufgelistet. Des Weiteren existiert in OSM bereits eine international eindeutige Nummer zur Referenzierung von ÖPNV-Haltestellen: die IFOPT (Identification of Fixed Objects in Public Transport). Die flächendeckende Datenerhebung hinsichtlich Barrierefreiheit an Haltestellen könnte also unter Verwendung der IFOPT zusammen mit den vorgeschlagenen, äquivalenten Tags erfolgen, indem fehlende Informationen in OSM um die mittels der App erhobenen Daten ergänzt wird. Diese Daten können aus der OPENER-Datenbank extrahiert und in die OSM-Datenbank importiert werden. Dazu werden im Vortrag Import-Konzepte präsentiert und zur Diskussion gestellt. # Referenzen [OPENER Projekt-Webseite](https://www.bmvi.de/SharedDocs/DE/Artikel/DG/mfund-projekte/opener.html) [OPENER App-Repository](https://gitlab.hrz.tu-chemnitz.de/opener/opener-app/) [OPENER OSM Wiki](https://wiki.openstreetmap.org/wiki/User:OPENER/DELFI_OSM_Tags) [IFOPT Wiki-Eintrag]( https://wiki.openstreetmap.org/wiki/DE:Key:ref:IFOPT) # Acknowledgements Das Projekt „OPENER“ startete im März 2019 und wird im Rahmen der Förderrichtlinie „Modernitätsfonds“ (mFUND) mit insgesamt 97.110 Euro durch das Bundesministerium für Verkehr und digitale Infrastruktur (BMVI) gefördert. about this event: https://pretalx.com/fossgis2020/talk/3F8JCB/

Die Digitalisierung fordert die Verfügbarkeit jeglicher staatlichen Dienstleistung über digitale Kanäle. Geodatenhaltende Stellen müssen dazu eine vergleichsweise große Datenmenge verarbeiten. Monolithische Altverfahren sind aufgrund mangelnder Zuverlässigkeit, Flexibilität und Skalierbarkeit nahezu ungeeignet, diesen Anforderungen adäquat zu begegnen. Vorgestellt wird, wie durch moderne Architekturen und Technologien des Cloud Computing Geodaten effizient verarbeitet werden können. Mit Kubernetes wird eine containerbasierte Plattform aufgesetzt, die horizontale Skalierung der zugrundeliegenden Rechenkapazität und bereitgestellten Applikationen ermöglicht. Für den Anwendungsfall geeignete Applikationen sind OpenFaaS und Minio. OpenFaaS ermöglicht die hoch-skalierbare Verarbeitung in unterschiedlichen Programmiersprachen. Ein- und Ausgabedaten werden für Write-Once-Read-Many Zugriffe optimiert im ObjectStore Minio gespeichert. Am Beispiel des Kampfmittelbeseitigungsdienstes Niedersachsen werden Szenarien für die Transformation und Analyse von historischen Kriegsluftbildern auf dieser Plattform dargestellt und insbesondere die Vorteile der Speicherung von Rasterdaten im Format cloud-optimized GeoTIFF in diesem Kontext aufgezeigt. about this event: https://pretalx.com/fossgis2020/talk/7MSDDM/

Der Vortrag geht vor allem auf die Entstehung der heterogenen Datenqualität in OpenStreetMap und die Umsetzung der intrinsischen und extrinsischen Qualitätsbewertungsmethode ein. Die Methoden bewerten die OSM-Datenqualität basierend auf der OSM-Datenhistorie (intrinsisch) und im Vergleich zu amtlichen ALKIS-Gebäudedatensätzen (extrinsisch). Das Volunteered Geographic Information-Projekt OpenStreetMap (OSM) stellt aktuelle, global und frei zur Verfügung stehende Geodatensätze bereit. Diese Datensätze werden für verschiedene Anwendungen verwendet und sind eine alternative Datenquelle zu amtlichen Daten oder Fernerkundungsdaten (wie Satellitenbilder). Ein großer Nachteil der OSM-Daten besteht in der heterogenen Datenqualität. Beispielsweise ist die Validität der OSM-Gebäudedaten für eine Verwendung in einer Expositionsabschätzung bei einem Hochwasser (= Abschätzung betroffener Gebäude und Personen) fragwürdig. Für diese Daten existiert keine stabile und standardisierte Qualitätsbewertungsmethode. Daher bedarf es eigener Qualitätsbewertungsmethoden. Im Rahmen einer Masterarbeit wurde eine intrinsische und extrinsische Qualitätsbewertungsmethode für OSM-Gebäudedaten unter Verwendung in einer Expositionsabschätzung entwickelt und umgesetzt. Zur Bewertung dienen intrinsische Indikatoren und extrinsische Maße, die für bestimmte Qualitätskriterien (Vollständigkeit, geometrische Genauigkeit ...) und die Beitragsaktivität erarbeitet und umgesetzt wurden. Hierzu kamen für die intrinsischen Indikatoren die OpenStreetMapHistoryDatabase (OSHDB)-API des Heidelberg Institute for Geoinformation Technology (HeiGIT) und für die extrinsischen Maße zur Aufbereitung/Import der Daten (osmosis, osm2pgsql und norGIS-ALKIS) sowie eine PostgreSQL/PostGIS-Datenbank zum Einsatz. Die Bewertungen der Gebäude-Daten erfolgte im Bereich der Überschwemmungsflächen für die Stadtgebiete Köln und Gera. about this event: https://pretalx.com/fossgis2020/talk/UKFLSU/

GeoStyler ist eine Open Source JavaScript-Bibliothek zur einfachen Erstellung von modernen Web-Oberflächen zum kartographischen Stylen von Geodaten. Somit wird es dem Anwender möglich ohne Programmierung und Editieren von Text-Dateien (XML und co.) Styling-Vorschriften interaktiv zu gestalten und diese in diverse offene Style-Formate zu überführen. Der Vortrag stellt die Neuerungen des letzten Jahres vor und gibt einen Überblick über zukünftige Entwicklungen im GeoStyler Projekt. GeoStyler ist eine Open Source JavaScript-Bibliothek zur einfachen Erstellung von modernen Web-Oberflächen zum kartographischen Stylen von Geodaten. Somit wird es dem Anwender möglich ohne Programmierung und Editieren von Text-Dateien (XML und co.) Styling-Vorschriften interaktiv zu gestalten und diese in diverse offene Style-Formate zu überführen. Dazu können auch die zu stylenden Geodaten hochgeladen und verknüpft werden, so dass attribut-basierte Styles auf einfache Art erstellt werden können. Aktuell werden im GeoStyler folgende Formate unterstützt: **Style-Vorschriften** - OGC SLD - OpenLayers Styles - QGIS Styles - Mapbox Styles **Geodaten-Formate** - GeoJSON - OGC WFS - Shapefile Auf der FOSSGIS 2019 wurde das GeoStyler Projekt bereits präsentiert. In diesem Jahr sollen die Neuerungen des letzten Jahres anhand aktueller Beispiele, in denen der GeoStyler zum Einsatz kommt, präsentiert werden. Dazu gehört die u. a. die GeoStyler GeoServer Extension, die es erlaubt die Stile der GeoServer Layer direkt im GeoServer mittels graphischer Oberfläche zu editieren. Außerdem wird es einen Überblick über zukünftige Entwicklungen im Projekt gegeben. Quellcode auf github: https://github.com/geostyler/geostyler Online-Dokumentation: https://geostyler.github.io/geostyler/latest/index.html Demo: https://www.geostyler.org about this event: https://pretalx.com/fossgis2020/talk/M73SCJ/

ÖV-Stationen bestehen üblicherweise aus mehreren Punkt-, Linien- oder Flächeninformationen, z.B. Haltepunkten, Gleisen oder Bahnhofsgebäuden u.a.. Diese Objekte können in OSM mittels übergeordneter Relationen verknüpft werden, allerdings fehlt diese Gruppierung häufig oder ist unvollständig. Wir stellen ein Tool vor, das die Elemente von ÖV-Stationen als Paare von Stationsnamen und -koordinaten abstrahiert und mittels Ähnlichkeitsmaßen und maschinellem Lernen OSM-Stationen korrigieren kann. Wir stellen ein Tool (staty) vor, das aus ÖV-Stationsdaten in OSM Tupel von Stationsnamen und -koordinaten extrahiert. Die in OSM bereits als gruppiert markierten Stationen werden als ground truth verwendet und damit ein Klassifikator trainiert, der entscheiden kann, ob zwei Name/Koordinate Tupel dieselbe Station beschreiben. Die Hauptschwierigkeit liegt darin, dass dieselben Stationen teilweis deutlich voneinander abweichende Bezeichnungen haben können (z.B. "Hbf" vs. "Freiburg im Breisgau, Hauptbahnhof"), dass z.B. Ortsnamen für die Ähnlichkeit zweier Stationen irrelevant sind, wenn sie nah beieinander liegen, oder dass die mittlere Distanz von z.B. Haltepunkten derselben Stationen abhängig ist von der Art der Stationen. Z.B. wird die mittlere paarweise Distanz zwischen Haltepunkten in einer Station "Hauptbahnhof" üblicherweise deutlich größer sein als in einer Station "Dorfstraße". Wir nutzen unseren auf OSM-Daten trainierten Klassifikator, um die OSM-Daten selbst wieder zu korrigieren. Dazu führen wir ein auf den Ähnlichkeitswerten unseres Klassifikators beruhendes Clustering durch und geben die Differenz zwischen dem Clustering und der Stationsgruppierung in OSM als Editiervorschläge aus. Da unser Ansatz z.B. auch verschiedene Namen (ref_name, alt_name, name, ...) innerhalb einzelner Nodes als separate Elemente extrahiert, können auch Fehler innerhalb einzelner Nodes erkannt werden (z.B. ein nicht korrekt durch alle Namen nachgeführter Namenswechsel oder Schreibfehler). about this event: https://pretalx.com/fossgis2020/talk/VAXSHT/

www.tambora.org bietet über 250000 historische Einträge zum Thema Umwelt- und Klima, differenzierbar nach Zeit, Ort und thematischen Schwerpunkt. Durch die vorgestellten Libraries lassen sich diese einfach in eigene Leaflet- oder OpenLayer-Karten einbinden und reichern diese so durch wertvolle Informationen zur räumlichen und zeitlichen Verteilung vergangener Ereignisse an. Das für jeden zugängliche (und erweiterbare) Webportal www.tambora.org bietet über 250000 zeitlich differenzierbare und räumlich verortete Ereignisse. Im mitteleuropäischen Bereich finden sich für die letzten tausend Jahre Einträge zu den Themen Klima (beispielsweise Hitze, Kälte, Niederschlag, ...), Phenologie (etwa Erntequalität, -quantität und -zeitpunkt) und sozioökonomische Auswirkungen (Preisentwicklungen, Hunger, Aufstände, …). Um eigene Kartenapplikationen um Layer dieser Daten ergänzen zu können, werden Javascript-Bibliotheken für Leaflet und Openlayer vorgestellt. Die Anwendung der Bibliothek wird jeweils durch eine Anwendung verdeutlicht, wie z.B. ein [Dürre-Explorer](https://climdata.github.io/cook2015). about this event: https://pretalx.com/fossgis2020/talk/EBMZWN/

ÖV-Stationen bestehen üblicherweise aus mehreren Punkt-, Linien- oder Flächeninformationen, z.B. Haltepunkten, Gleisen oder Bahnhofsgebäuden u.a.. Diese Objekte können in OSM mittels übergeordneter Relationen verknüpft werden, allerdings fehlt diese Gruppierung häufig oder ist unvollständig. Wir stellen ein Tool vor, das die Elemente von ÖV-Stationen als Paare von Stationsnamen und -koordinaten abstrahiert und mittels Ähnlichkeitsmaßen und maschinellem Lernen OSM-Stationen korrigieren kann. Wir stellen ein Tool (staty) vor, das aus ÖV-Stationsdaten in OSM Tupel von Stationsnamen und -koordinaten extrahiert. Die in OSM bereits als gruppiert markierten Stationen werden als ground truth verwendet und damit ein Klassifikator trainiert, der entscheiden kann, ob zwei Name/Koordinate Tupel dieselbe Station beschreiben. Die Hauptschwierigkeit liegt darin, dass dieselben Stationen teilweis deutlich voneinander abweichende Bezeichnungen haben können (z.B. "Hbf" vs. "Freiburg im Breisgau, Hauptbahnhof"), dass z.B. Ortsnamen für die Ähnlichkeit zweier Stationen irrelevant sind, wenn sie nah beieinander liegen, oder dass die mittlere Distanz von z.B. Haltepunkten derselben Stationen abhängig ist von der Art der Stationen. Z.B. wird die mittlere paarweise Distanz zwischen Haltepunkten in einer Station "Hauptbahnhof" üblicherweise deutlich größer sein als in einer Station "Dorfstraße". Wir nutzen unseren auf OSM-Daten trainierten Klassifikator, um die OSM-Daten selbst wieder zu korrigieren. Dazu führen wir ein auf den Ähnlichkeitswerten unseres Klassifikators beruhendes Clustering durch und geben die Differenz zwischen dem Clustering und der Stationsgruppierung in OSM als Editiervorschläge aus. Da unser Ansatz z.B. auch verschiedene Namen (ref_name, alt_name, name, ...) innerhalb einzelner Nodes als separate Elemente extrahiert, können auch Fehler innerhalb einzelner Nodes erkannt werden (z.B. ein nicht korrekt durch alle Namen nachgeführter Namenswechsel oder Schreibfehler). about this event: https://pretalx.com/fossgis2020/talk/VAXSHT/

Mit Wegue lassen sich WebGIS-Anwendungen durch eine einfache Konfigurationsdatei erstellen. Es beinhaltet bereits gängige Funktionenen wie Layerswitcher oder Geocoding. Durch die modulare Struktur kann Wegue jedoch auch leicht erweitert und individuell angepasst werden. Wegue [1] ist eine Software zum Erstellen von modernen leichtgewichtigen WebGIS-Client-Anwendungen. Die Basis dafür sind die beiden Open Source JavaScript-Frameworks OpenLayers [2] und Vue.js [3]. OpenLayers übernimmt dabei das Lesen und die Darstellung der Geoinformationen als Karte und die Prozessierung der Geo-Objekte. Vue.js wird für die Strukturierung des Projektcodes (nach MVVM) genutzt und erlaubt die Erzeugung von eigenen Web-Komponenten. Wegue verknüpft diese beiden Bibliotheken zu einer konfigurierbaren Vorlage für WebGIS-Anwendungen aller Art und stellt wiederverwendbare UI-Komponenten (z.B. Layer-Liste, FeatureInfo-Dialog, etc.) bereit. Wegue wurde kurz nach der Projektgründung auf der FOSSGIS 2018 in Bonn präsentiert. Mittlerweile ist das Projekt gereift und in einigen Realweltprojekten zum Einsatz gekommen. Dabei ist es an vielen Stellen erweitert und verbessert worden und befindet sich aktuell auf dem Weg zur Version 1.0. Der Vortrag gibt einen kurzen Überblick über das Wegue-Ökosystem sowie die Neuerungen der letzten Monate und zeigt wie Wegue-Anwendungen erstellt werden können. Außerdem werden einige Beispiele aus der Praxis präsentiert. [1] https://github.com/meggsimum/wegue [2] http://openlayers.org/ [3] https://vuejs.org/ about this event: https://pretalx.com/fossgis2020/talk/GHET3U/