FOSSGIS 2014 (mp4)

In Forschungsprojekten, an denen mehrere Personen beteiligt sind, stellt die Datenverwaltung häufig eine große Herausforderung dar. Unterschiedliche Datenformate, die Speicherung der Daten auf verschiedenen lokalen Datenträgern, Datenverluste und ungenügende Dokumentation können für erhebliche Probleme sorgen. Auch der Austausch der aktuellen Datenbestände unter den Projektteilnehmern kann Schwierigkeiten bereiten, was die Zusammenarbeit in Forschungsprojekten weiter einschränken kann. Aus diesen Gründen wurde an der Physischen Geographie der Uni Freiburg ein webbasiertes Werkzeug entwickelt, welches das kollaborative Arbeiten mit Geodaten vereinfachen soll. Der Fokus lag dabei auf niedrigen Zugangshürden, Benutzerfreundlichkeit und hoher Flexibilität beim Export der Daten, um eine problemlose Weiterverarbeitung in gängigen Programmen zu ermöglichen. Gerade für das Bearbeiten räumlicher Daten sind normalerweise spezielle Software und Kenntnisse erforderlich. Als webbasierte Applikation stehen die zur Dateneingabe erforderlichen Werkzeuge online zur Verfügung und eine intuitiv zu bedienende Benutzeroberfläche ermöglicht die Nutzung auch ohne spezielle GIS-Kenntnisse. Weiterhin sorgt die Webapplikation für eine standardisierte Datenspeicherung, Datenvalidierung und ermöglicht das einfache Sichern und Archivieren der Daten. Die Webapplikation besteht aus einem in der Skriptsprache PHP geschriebenen Hauptprogramm. Darüber hinaus wurde auf verschiedene Open-Source-Komponenten zurückgegriffen, darunter die Webserver-Software Apache HTTP Server, das Datenbankmanagementsystem PostgreSQL mit der Geodaten-Erweiterung PostGIS und die Web-Mapping Bibliothek OpenLayers. Durch die Verwendung dieser frei verfügbaren Komponenten war es möglich, innerhalb kurzer Zeit und mit geringen Kosten ein praxistaugliches Werkzeug zur kollaborativen Geodatenverwaltung zu entwickeln.

Das von der EU finanzierte Umweltforschungsprojekt CLIMB (Climate Induced Changes on the Hydrology of Mediterranean Basins; www.climb-fp7.eu) untersucht die Auswirkungen des Klimawandels auf die Hydrologie und das Management von Wasserressourcen im mediterranen Raum. Aufgabe eines Teilprojektes war der Aufbau eines Geodatenportals für den projektinternen Austausch von Geodaten und die Bereitstellung der auf verschiedenen Klimaszenarien aufsetzenden hydrologischen Ergebnisdaten (wie Oberflächenabfluss, Trockenperioden, Bodenfeuchte) in Form von Karten, tabellarischen Zeitreihendaten und automatisiert generierten Abbildungen hydrologisch relevanter Zeitreihendaten. Die zu verwendende Softwarelösung sollte den Projektpartnern eine individuelle Verwaltung der von ihnen in das Portal eingestellten Daten ermöglichen. Um darüber hinaus das Einbinden projektspezifischer Funktionalitäten zu gestatten, sollte die Software erweiterbar sein. Die hier beschriebene Geoportallösung basiert auf GeoNode (Ver. 2.0b64), da dieses System nicht nur die o.g. projektseitigen Anforderungen erfüllt, sondern auch ein für EinsteigerInnen geeignetes „GDI-Gesamtpaket“ mit Metadatenkatalog (pycsw), Kartenserver (GeoServer) und WMS-Client (OpenLayers + GeoExt) ist. Dieser Beitrag schildert die Erfahrungen mit GeoNode2.0 als Geoportallösung für ein internationales, wissenschaftliches Großprojekt. Dabei wird auf die Nutzung von GeoNode als Content Management System eingegangen und dargestellt, welche besonderen Herausforderungen sich mit Blick auf die unterschiedlichen nationalen Standards in der Haltung von Geodaten ergeben. In diesem Zusammenhang wird gezeigt, wie GeoNode mittels Django und JavaScript zwecks Bereitstellung und Visualisierung der Zeitreihendaten erweitert wurde und welche Tools sich als hilfreich im Umgang mit großen Datenmengen in GeoNode erwiesen haben. Im Einzelnen werden dabei die python-Pakete „gsconfig“ und „psycopg2“ kurz vorgestellt.

OpenData ist in aller Munde... aber wie sieht es in der Praxis aus? Erfahrungen mit Bundes- und Landesbehörden in DE und international. OpenSeaMap hat in den letzten Monaten mit vielen Behörden sehr positive Erfahrungen gemacht: - Bundesamt für Seeschiffahrt und Hydrogrphie - Wasser- nd Schiffahrtsverwaltung - Bundesamt für Kartographie und Geodäsie - SwissTopo - Land Bayern - Land Baden-Würtemberg - Land Vorarlberg und weitere Behörden Manchmal steckt der Teufel im Detail... ;-)

Das Schlagwort OpenData geistert seit einiger zeit durch Deutschlands Verwaltungen. Und zu Recht, denn immer mehr Menschen interessieren sich heutzutage für öffentlich zugängliche Daten, insbesondere auch für Geodaten - zahlreiche Beispiele für kostenfreie Services und Anwendungen, die die Geodaten als OpenData für den Nutzer frei zur Verfügung stellen, finden sich im Internet. Es geht hierbei außerdem häufig nicht nur um reines „Gucken“, sondern zunehmend auch um das Mitmachen und Mitgestalten von Geodaten durch den Nutzer selbst. OpenStreetMap ist ein leuchtendes Beispiel dafür. Aus diesen Überlegungen heraus wurde 2012 in einer Vorstudie geprüft, wie sich die Stadt Ulm am OpenData-Gedanken beteiligen kann. Im Frühjahr 2013 wurde dann das Projekt „map-it.ulm.de“ als eine Anwendung zum Sammeln von freien Daten über die Bürger einer Stadt im Rahmen der Gesamtumsetzung des öffentlichen Geoportals der Stadt Ulm verwirklicht. Das Projekt hat mit der 1. Aktion „Zeig mir deinen Lieblingsplatz!“ Ende Juni 2013 begonnen. Das Ziel war, die meist geliebten Orte in Ulm und Umgebung, aufgeteilt in 5 Kategorien, über Eintragung in der Karte durch Ditigalizieren zu sammeln und diese zu bewerten. Zu diesem Zweck wurde eine auf der OpenSource JavaScript Bibliotheken Ext JS 4.1.1, OpenLayers 2.12 und GeoExt 2 GIS-Applikation entwickelt. Durch die benutzerfreundliche Bedienung und zahlreiche Texthinweise konnte die Eintragung von Lieblingsplätzen sehr intuitiv gestaltet werden. In knapp 2 Wochen wurden auf diese Art und Weise über 450 POIs gesammelt, mehr als 900 Menschen haben am Projekt teilgenommen. Der gesammelte Datensatz wurde anschließend im Geoportal der Stadt Ulm veröffentlicht, mit den OSM POI-Daten abgeglichen und ist jederzeit zum Anschauen und Download als Open Data abrufbar. Dieser Vortrag soll einen Ausblick über verwendete Techniken und Ideen zur Projektrealisierung geben und diskutieren, ob und wie dies ein Weg sein kann, einfache POI-Daten, auch für OpenStreetMap zu sammeln.

Der Straßenverkehr ist ein entscheidender Faktor für die Umweltbelastung und Lebensqualität in Städten. Um seine Auswirkungen optimal abschätzen zu können und die Planung von Maßnahmen wie verkehrsberuhigte Zonen zu unterstützen, ist eine solide Datenbasis unverzichtbar. Über Verkehrszählungen oder die Auswertung von Mobilfunknetzten ist es zwar bereits möglich Daten über Verkehrsdichte und -fluss zu erhalten. Aussagen über Umwelteinflüsse sind hieraus aber nicht direkt abzuleiten. Gleichzeitig verfügen jedoch nahezu alle aktuellen Fahrzeuge über zahlreiche Sensoren, welche weitere Messdaten liefern aus denen sich relevante Umwelteinflüsse ableiten lassen (z.B. Lärmemission, Kraftstoffverbrauch und CO2-Ausstoß). In diesem Vortrag wird das enviroCar-Projekt (http://enviroCar.org) vorgestellt. Grundidee dieses Projekts ist die Entwicklung einer Crowdsourcing-Lösung welche die in Fahrzeugen verfügbaren Messdatenquellen für weitergehende Analysen und Auswertungen erschließt. Hierfür wird die standardisierte OBD2-Schnittstelle genutzt, welche einen Zugang zu den von einem Auto erhobenen Messdaten ermöglicht. Durch die Kopplung dieser OBD2-Schnittstelle an Smart Phones (über einen Bluetooth-Adapter) ist es möglich, die gemessenen Daten zu sammeln und an einen zentralen Datenserver zu übertragen. Neben konzeptionellen Aspekten (insbesondere Architektur und Datenschutz) stellt dieser Vortrag die zugrundeliegende Implementierung auf Basis von Open Source-Software vor.

Das von der Toll Collect GmbH betriebene System zur Erhebung und Abrechnung der Lkw-Maut auf deutschen Autobahnen und Bundesstraßen basiert u.a. auf genauen und aktuellen Straßendaten. Auf Basis von Straßenkarten kommerzieller Anbieter und Vermessungsdaten einer eigenen Messflotte pflegen und optimieren wir seit nunmehr über einem Jahrzehnt eine Straßenkarte höchster Qualität. Doch nicht immer reichen die Informationen aus der kommerziellen Karte, der Messflotte oder auch dem Baustelleninformationssystem des Bundes aus, um Veränderungen im Straßennetz rechtzeitig zu erkennen. In den letzten Jahren wurde daher OpenStreetMap als zusätzliche Informationsquelle eingesetzt. Die OSM-Karte wird als zusätzliche Basiskarte im betrieblich eingesetzten GIS verwendet. Vektordaten und Veränderungen in den Straßengeometrien aus OSM werden für diverse Analysen regelmäßig eingesetzt und im für uns relevanten mautpflichtigen Netz ausgewertet. Für zahlreiche Anwendungsfälle der Toll Collect haben sich die Daten der OpenStreetMap bewährt, dennoch können wir noch nicht auf die klassischen Kartenanbieter verzichten. Wir möchten berichten, was uns davon abhält, OSM-Daten noch enger in unseren Produktivbetrieb einzubinden und welche Potenziale, aber auch welche Schwächen wir in der heutigen OSM sehen.

Die Einsatzkarte : eine interaktive Karte für freiwillige Rettungskräfte Wir, die Küstenschmiede entwickeln Web-Anwendungen, die vorzugsweise interaktive Karten integrieren. Dabei setzen wir in erster Linie auf OpenStreetMap, OpenLayers, die Overpass-API und auf das Open-Source Content-Management-System Contao. Wir haben für das CMS den Erweiterungsbaukasten con4gis geschrieben, der Module bereitstellt, die es einfach machen, interaktive Karten ohne Programmierkenntnisse zu integrieren. Dies soll u.a. auch dazu beitragen dass die OpenStreetMap weitere Verbreitung findet. Aktuell arbeiten wir zusammen mit dem Kreisfeuerwehrverband Friesland an einer OSM-basierten Einsatzkarte für freiwillige Rettungskräfte, die es ermöglichen wird, die Einsätze besser vorzubereiten und zu planen. Dazu haben wir bereits z.B. mehrere tausend Hydranten in die OSM eingespielt. Noch befindet sich die Einsatzkarte im beta-Test, sie soll jedoch spätestens zum Januar 2014 online gehen und weiteren freiwilligen Rettungsverbänden vorgestellt werden. In unserem Vortrag möchten wir über das Projekt berichten, die Anwendungsszenarien für die Einsatzkräfte darstellen und nicht zuletzt die technische Umsetzung erläutern. Wir freuen uns, wenn wir auf der FossGis 2014 unser Projekt ‚Einsatzkarte‘ in einem Vortrag präsentieren dürfen.

OpenStreetMap und andere freie Geodaten sind heutzutage eine Selbstverständlichkeit im Alltag. Ob Navigationsgerät, Smartphone-App oder im Browser, interaktive Karten(anwendungen) findet man überall. Wie sieht es aber aus wenn die Geodaten auf Papier gedruckt werden sollen? Ein Screenshot ist schnell gemacht, Datei -> Drucken und man hat eine Karte in der Hand. Ganz so einfach ist es nicht, wenn man bestimmte Anforderungen zu erfüllen hat. Wo kann man mal eben schnell eine Karte im DIN A0 Format oder größer ausdrucken? Wie wird eine so große Druckdatei erzeugt? Dieser Vortrag beschreibt den Versuch eine Schullandkarte zu erstellen. Dabei wird ausschließlich auf freie Geodaten, insbesondere OpenStreetMap, sowie freie Software gesetzt. Es wird der komplette Prozess beschrieben. Welche Datenquellen werden benutzt? Wie müssen die Geodaten aufbereitet werden? Welche Software rendert Karten im Quadratmeterformat? Wo liegen die Hürden, die Grenzen und wie kommen die Karte letztendlich auf das Papier und an die Wand? Es soll nicht zuviel vorweggenommen werden. Die technischen Anforderungen werden von handelsüblicher, freier Software bereits heutzutage erfüllt. Der Aufwand entsteht bei der Auswahl und Aufbereitung der Geodaten. Ebenso ist es sehr sinnvoll grundlegende kartographische Kenntnisse für so ein Projekt mitzubringen. Was im Detail herausgefunden wurde, wird präsentiert und zur Diskussion gestellt.

Wie entsteht ein kommerzielles Freizeitprodukt auf Basis von Open Data und Open Source Software? Die in vielen Fällen bereits flächendeckende Verfügbarkeit von OpenStreetMap eröffnet neue Möglichkeiten für die Herstellung von kommerziellen Produkten. Am Beispiel von SplashMaps werden einige technische Herausforderungen und deren Lösungen mit Hilfe von Open Source Software vorgestellt. Des weiteren werden Lizenzfragen diskutiert, vor allem auch welche zusätzlichen Hürden entstehen, wenn andere Open Data Quellen genutzt werden, die oft nicht, oder anders lizenziert sind als OpenStreetMap.

geOrchestra besteht aus einer Open Source Community um eine INSPIRE konforme Geodateninfrastruktur aufzubauen. Das Ergebnis ist eine anpassbare, interoperable und freie INSPIRE GDI, basierend auf den besten Open Source Komponenten. Auf Github gehostet, bietet geOrchestra eine Lösung zur Publikation und Nutzung räumlicher Daten im Internet und Intranet. Das Projekt geOrchestra besteht aus mehreren unabhängigen und interoperablen Anwendungen: ein Katalog, mit einer Funktion um Geodaten zu publizieren einen Viewer und einen Editor ein Tool um Daten zu extrahieren ein Kartendienst ein Content Mangement System (CMS) Diese Module sind voneinander unabhängig und die Kommunikation zwischen den Modulen geschieht über OGC-Standards. geOrchestra wurde konzipiert, um die Anforderungen der INSPIRE-Richtlinie zu erfüllen. Die INSPIRE-Richtlinie hat eine Geodateninfrastruktur auf Europäischer Ebene zum Ziel, um sich so den Herausforderungen einer nachhaltigen Entwicklung zu stellen: Discovery, View und Download von Geodatenservices Statischer Link zwischen den geografischen Daten und deren Metadaten INSPIRE-Standards Administrationstools um die INSPIRE zu verwalten (INSPIRE Themen, GEMET Thesaurus, INSPIRE-Konformitätsprüfung, etc.) Einfacher Gebrauch über Webservices Dieser Vortrag wird das geOrchestra Community Projekt beschreiben und den aktuellen Stand des Projekts besprechen.

Das vollständig auf FOSS basierende GeoPortal.rlp wurde seit seiner Inbetriebnahme im Januar 2007 sukzessive an die sich wandelnden Nutzeranforderungen angepasst. Es bildet die zentrale Komponente der Geodateninfrastruktur Rheinland-Pfalz (GDI-RP) und setzt das einer Serviceorientierten Architektur (SOA) zugrundeliegende Publish-Find-Bind Paradigma seit 7 Jahren konsequent und erfolgreich um. Im Gegensatz zu den allgemein verbreiteten GDI-Architekturen (z.B. GDI-DE und INSPIRE), deren Backends große Kataloge mit standardisierten Metadaten für Daten und Dienste bilden, basiert die GDI-RP auf dem Konzept einer Service-Registry. Dezentrale Stellen registrieren OGC konforme WMS und WFS (OWS) in einer zentralen Datenbank. Das zugrundeliegende Konzept wurde 2005 zu einem Zeitpunkt erstellt, zu dem es noch keine standardisierten Schnittstellen für den Austausch von Geo-Metadaten gab und basiert auf dem Prinzip eines Single Point of Access (SPA) als Datenquelle für alle innerhalb einer GDI benötigten Metadaten. Die Informationen werden dabei aus den Capabilities Dokumenten der OWS extrahiert und einer zentralen Recherche zugänglich gemacht. Das Prinzip erlaubt die Realisierung eines Metadatenproxies, der sowohl für Qualifizierungsmaßnahmen, als auch für eine zentrale Absicherung genutzt wird. Mit der ab 2007 beginnenden Umsetzung der INSPIRE-Richtlinie und ihrer Durchführungsbestimmungen in nationales Recht, ergaben sich neue Herausforderungen. Das auf einer "Standard GDI-Architektur" basierende Prinzip von INSPIRE stellt spezielle Anforderungen an die bereitzustellenden Daten, Dienste und deren Metainformationen und ist weltweit der erste reale Anwendungsfall für die ursprünglich vom OGC erarbeiteten Konzepte und Standards. Es fehlt bis heute noch an Softwareprodukten die diese Anforderungen vollständig umsetzen können. Um den ambitionierten Zeitplan der Richtlinie einhalten zu können, wurden in Rheinland-Pfalz verschiedene Verfahren entwickelt, die es den Datenanbietern erlauben, die bisherigen etablierten GDI Standards WMS 1.1.1 sowie WFS 1.1.0 weiterzuverwenden, ohne ihre Basissoftware anpassen zu müssen. Die komplexen Anforderungen werden dabei zentral über eine "INSPIRE-Proxy" Funktionalität der Service-Registry erfüllt. Mit dieser Vorgehensweise ist Rheinland-Pfalz das einzige Flächenland, dass bisher alle von der Richtlinie gesetzten Fristen einhalten konnte. Neben der Fassade für die INSPIRE-konformen Darstellungs- und Downloaddiensten umfasst das Verfahren auch die automatisierte Bereitstellung der für das EU-Berichtswesen geforderten "Monitoring"-Informationen. Alle entwickelten Funktionen sind in die zugrundeliegende OSGEO Software Mapbender2 zurückgeflossen und stehen damit frei zur Verfügung. Zusätzlich gibt es das komplette Portal auch in Form einer VM zum Download. Im Vortrag werden die zugrundeliegenden Prinzipien der INSPIRE-Umsetzung kurz erläutert und die implementierten Funktionen anhand praktischer Beispiele vorgestellt. Außerdem soll ein Ausblick auf das grundsätzliche Potential gegeben werden, das trotz aller auftretender Probleme in INSPIRE steckt.

Der Zeitplan der europäischen Geodateninfrastruktur INSPIRE sieht die Bereitstellung von Darstellungs- und Downloaddiensten – für die im Anhang III der Richtlinie aufgeführten Themen – ab Dezember 2013 vor. Für die Realisierung von INSPIRE-Darstellungsdiensten werden zunehmend OGC-konforme WMTS-Dienste eingesetzt. Im Gegensatz zu den etablierten WMS-Diensten gelten „gecachte“ Dienste als einfach und performant. Aufgrund der fehlenden Flexibilität sind sie jedoch nicht für jeden Anwendungsfall geeignet. Im Vortrag wird der OGC WMTS-Standard erörtert und auf die konkreten technischen Empfehlungen (Technical Guidance) seitens INSPIRE eingegangen. Weiterhin stellt die Realisierung von INSPIRE-Downloaddiensten die Datenanbieter seit 2012 vor Herausforderungen. Die WFS 2.0 Implementierung von GeoServer und deeegree wurde weiter verbessert, zudem wurde im Oktober 2013 mit der WFS 2.0 Implementierung für den UMN MapServer begonnen. Der Status Quo der INSPIRE-geeigneten FOSS WFS 2.0 Implementierungen wird betrachtet. Des Weiteren finden INSPIRE Pre-defined Atom-Downloaddienste zunehmende Verbreitung. Die Funktionsweise von INSPIRE-Downloaddiensten auf Grundlage von Atom-Feeds (GeoRSS) und OpenSearch wird ausführlich vorgestellt. Atom-Feeds mit INSPIRE-Erweiterung können inzwischen u. a. mit der beliebten Java-Bibliothek ROME gelesen und geschrieben werden. INSPIRE-Downloaddienste können – neben der Verwendung in klassischen Desktop-GIS – zur automatisierten Aktualisierung lokaler Geodatenrepositorien eingesetzt werden. Am Beispiel der gdal/ogr-Bibliothek werden verschiedene Einsatzmöglichkeiten betrachtet.

Die Grundlagen der Satellitenpositionsbestimmung sind den meisten wohl bekannt. Dennoch bieten die Funktionsweise und Betriebsbedingungen von GPS und Co. viele interessante und spannende Details. Z.B. wurde der künstliche Fehler von GPS abgeschaltet, damit das US-Militär erhöhte Positionsgenauigkeit im Golfkrieg erhielt. Dieser Vortrag führt in die Funktionsweise von GPS ein, und zeigt viele Erweiterungen zur Erhöhung der Genauigkeit, die von den Systemarchitekten nie vorgesehen waren. Dies führt bis zu modernen Verfahren für RTKs, die in Echtzeit Positionsbestimmungen im Millimeterbereich ermöglichen. Neben dieser Funktionsbeschreibung soll der Vortrag vor allem aber auch einen Überblick bieten, wie diese Hochgenauigkeit mit kleinen Tricks auch mit handelsüblicher Hardware und OpenSource-Software möglich ist und wieviel davon auch im Handy erreicht werden kann. Dass diese exakte Positionsbestimmung auch in Zeiten hochauflösender Satellitenbilder nicht nur dem Selbstzweck dient wird abschließend anhand möglicher Anwendungen aufgezeigt und vorgestellt.

Survey2GIS ist eine kompakte und benutzerfreundliche Lösung, um Tachymeterdaten einer Grabung für die Weiterverarbeitung in einem GIS aufzubereiten. Dabei werden zwei- oder dreidimensionale Punktmessdaten zu komplexen Geometrien (Linien und Polygonen) verbunden. Als Eingabedaten erwartet survey2gis eine oder mehrere einfache Textdateien, wobei jede Zeile die Koordinaten eines Punktes und die Attributdaten hierzu enthält. Derart strukturierte Daten können nicht nur tachymetrisch per Totalstation, sondern auch per GPS-Vermessung gewonnen werden. Auf dieser Grundlage erzeugt Survey2GIS GIS-Dateien im Format ESRI(tm) Shapefile (2D oder 3D), nach Geometrietypen getrennt, mit Übernahme der vollständigen Attributdaten. Dieser Prozess lässt sich so konfigurieren, dass unterschiedlichste Arbeitsabläufe und Datenstrukturen unterstützt werden. Die Software verfügt über detaillierte Protokollfunktionen zur Qualitätssicherung und automatischen Dokumentation der Datenverarbeitung. Bei der Entwicklung von survey2GIS wurde größter Wert auf topologisch korrekte Ausgabedaten gelegt, die sich direkt für die quantitative Analyse im GIS eignen. Hierzu gehören Funktionen zum Eliminieren doppelter Messpunkte, zum Einrasten von Stützpunkten auf Polygongrenzen und zum "Ausstanzen" überlappender Polygone. Die freie Software (GNU General Public License) läuft unter Windows und Linux-Betriebssystemen. Dabei steht die erste Version 1.x von surveying sowohl als eigenständige Software als auch als Zusatz für das Open-Source-Desktop-GIS gvSIG CE zur Verfügung.

Autoren: Freckmann, Peter und Denis Majnaric Einsatzmöglichkeiten von Open Source GIS im Geomarketing Im modernen Marketing eines Unternehmens wächst der Bedarf an Geomarketing-Funktionalitäten ständig. Jedoch werden viele Unternehmen von der Tatsache, dass ein Software-Paket und die passenden Daten sehr kostenintensiv sind, abgeschreckt. Trotzdem können viele Unternehmen nicht auf entsprechende Tools verzichten. In den letzten Jahren entstand ein großer Markt für frei zugängliche Software, darunter auch Geographische Informationssysteme (Open Source GIS), die als Basis für Analysen im Geomarketing dienen können. Dieser Markt wächst stetig weiter. Der Beitrag soll die Einsatzmöglichkeiten von Open Source GIS im Geomarketing analysieren (use cases) und aufzeigen, welche Systeme sich für Fragestellungen im Geomarketing besonders eignen. Auf Basis von verschiedenen Kriterien wird eine Evaluierung der Systeme durchgeführt und die daraus abgeleiteten Erkenntnisse für die optimale Wahl eines der gängigen Open Source GIS vorgestellt. Dabei stehen sowohl Aspekte des klassischen Marketings als auch insbesondere des Geomarketings im Vordergrund.

Liegen GIS-Daten normalisiert in relationalen Datenbanken vor, ist ihre Lesbarkeit aus dem GIS heraus durch die Beziehungen der beteiligten Tabellen untereinander meistens nicht mehr direkt gegeben. Darüberhinaus interessieren häufig räumliche Beziehungen zu Geometrieobjekten in anderen Tabellen. Anwender wünschen sich deshalb Datenblätter, die alle Informationen zu einem Objekt in einer les- und ausdruckbaren Form zusammenfassen. Für derartige Datenblätter sind dezidierte Reporting-Werkzeuge die erste Wahl, weil ein Desktop-GIS aufgrund seiner andersgelagerten Schwerpunkte voraussichtlich nie deren Möglichkeiten erreichen wird. Im Bereich der freien Software ist die in Java geschriebene JasperReports Library das bekannteste Reporting-Werkzeug. JasperReports bietet u.a. die Darstellung von Diagrammen und Graphiken sowie Punkten auf GoogleMaps. Die Werkzeuge IReport Designer bzw. Jaspersoft Studio stellen eine WYSIWYG-Oberfläche zur Verfügung, die es auch Einsteigern ermöglicht, Reportdateien herzustellen. Der Vortag zeigt, wie aus QGIS heraus mittels Python in einem LAN pdf-Dokumente mit der JasperReports Implementierung PyJasper erzeugt werden, die auch Kartenausschnitte des Geoobjekts enthalten können. Die anzuzeigenden Daten werden dafür in QGIS als XML-String formatiert und zusammen mit einer Reportdatei an den PyJasper-Server übertragen. Dort wird der Report kompiliert und mit den Daten ein pdf-Dokument gefüllt, das an QGIS zurückgegeben wird.

Die neuen Benutzerdienste der Europäischen Weltraumorganisation (ESA) verwenden aus Open Data generierte Karten. Die Geländekarte zum Beispiel basiert unter anderem auf OpenStreetMap, EU-DEM, und GlobCover Daten und wurde von EOX designed. Der Browse Server, zuständig für die standardkonforme Auslieferung von Karten und Vorschaubildern (Browse Images), basiert ausschließlich auf Open Source Software wie MapCache, EOxServer, MapServer und GDAL und wird im Rahmen des ngEO Projektes von EOX entwickelt. Der Vortrag stellt sowohl das Design der Karten als auch die Architektur und Funktionalität des Browse Servers vor.

Höhendaten aus Radarmessungen wie der Shuttle-Radar-Topography-Misssion (SRTM) lassen sich auch verwenden, um höhenbewusste Routing-Anwendungen zu implementieren. Der global verfügbare 90m-SRTM Datensatz ist dafür jedoch nur bedingt geeignet, da durch das grobe Raster grosse Interpolationfehler entstehen und ausserdem durch die nur teilweise Durchdringung des Radars durch Vegetation insbesondere an Waldkanten störende Artefakte entstehen. Gleichzeitig gibt es aber steigenden Bedarf für höhenbewusstes Routing, da mit dem Aufkommen der Elektromobilität nicht mehr nur Radfahrer mit dem Problem der begrenzten Energiereserven konfrontiert sind. Grund genug also, sich mal anzuschauen, was mit 90m-SRTM möglich ist. Höhenbewusstes Routing muss einerseits frei sein von Artefakten - Problemstellen wie enge Flusstäler, Waldkanten, Tunnel oder Hochhaussiedlungen dürfen also nicht mit unechten Höhensignalen Routingentscheidungen beeinflussen. Andererseits soll das Routing aber auch für kleinere Hügel sensitiv sein. Dieser Zielkonflikt erfordert einen sinnvollen Kompromiss in Form eines Tiefpassfilters, der kleinere Höhendifferenzen herrausfiltert, so dass letztlich keines der beiden Ziele vollständig erreicht werden kann. Deswegen soll der Frage nachgegangen werden, inwiefern mit besseren Höhendaten bessere Routingergebnisse erzielt werden können und die verfügbaren Daten gegenübergestellt werden.

Die Informationstiefe von OpenStreetMap wächst rasant und übertrifft teilweise die der kommerziellen Anbieter deutlich. Diese Informationen sind zumeist visuell als Karte zugänglich. Die Daten textuell durchsuchbar zu machen ist vergleichsweise komplizierter aber nicht weniger relevant. Aktuelle Open-Source-Lösungen zur Durchsuchung von OSM-Daten hinken deshalb den kommerziellen Angeboten deutlich hinterher. Komoot (www.komoot.de) hat erst kürzlich seinen intern entwickelten Geo-Coder *photon* als Open Source veröffentlicht. Damit ebnen wir den Weg zu einer gemeinschaftlichen Entwicklung eines Geo-Coders unter Verwendung des aktuellen Stands der Technik. Photon verwendet *Apache Solr*, eine effiziente und hochskalierbare Suchtechnologie mit zahlreichen Features, darunter Volltextsuche und räumliche Abfragen. Mehrsprachigkeit sowie kontinuierliche Suche während der Texteingabe werden unter anderem unterstützt. Der Vortrag wird auf die Problemstellung näher eingehen sowie die Stärken und Schwächen von photon beleuchten. Gerne stellen wir uns Fragen und Anregungen aus dem Publikum. Unter www.komoot.de kann *photon* im live Betrieb begutachtet werden, nähere Infos zum Projekt finden sich auf github: https://github.com/komoot/photon

Rendering maps on the client becomes more important as technologies emerge and devices get faster. While most maps are still served as raster tiles, there is a case for delivering vectors to the client. In this talk, I'll review existing rendering techniques and data formats, as well as point out their advantages and disadvantages. **Rendering Technologies:** Whether it's SVG or 2D Canvas to draw the map on the client, speed is always of the essence when . We're also going to have a look at using existing C/C++ based renderers in the browser. Finally WebGL and OpenGL open up a new world of possibilities for rendering on mobile and in the browser. It's a long way from the OpenStreetMap world extract to a manageable data size that we can serve to clients and process on weaker hardware. Additionally, data structures that are suited for rendering look different than for storing the raw source data. **Text Shaping and Rendering:** Typically, text shaping is one of the lower priority items, but it is vital for multilingual and multi-script maps in non-latin languages. We're going to look at open source software that can lay out text correctly and how to leverage it on the client side. **Interaction** with the map becomes a lot easier and more intuitive because all the raw data is available on the client and we can redraw the map based on user interaction without costly roundtrips to the server.

OpenStreetMap-Daten werden zunehmend für die Produktion von Landkarten aller Art eingesetzt. Hierbei wird jedoch fast immer, egal ob es sich um eine Weltkarte oder um einen Innenstadt-Plan handelt, die Darstellung direkt aus den Rohdaten erzeugt. Die eigentlich für gut lesbare Karten sehr wichtige Anpassung der Daten an den Maßstab und den Stil der zu erstellenden Karte (Generalisierung) wird vernachlässigt oder auf eine rein technische Datenvereinfachung reduziert. Dieser Vortrag stellt einige Ansätze für die automatische Generalisierung von OpenStreetMap-Daten auf Basis von Open-Source-Werkzeugen vor. Anhand von Küstenlinien, Gewässern und Gletschern wird beispielhaft erläutert, worauf es jeweils bei der Generalisierung ankommt und wie dies in einem automatischen Prozess berücksichtigt werden kann. Es werden die Herausforderungen beschrieben, die sich durch die permanenten Veränderungen der Datenbasis bei OpenStreetMap für die globale Anwendung eines solchen Verfahrens ergeben. Der Schwerpunkt des Vortrags liegt hierbei nicht so sehr auf den technischen Details, sondern er erläutert vor allem auch die Vorteile, welche sich für die Kartenqualität durch die Generalisierung ergeben sowie die Schwierigkeiten, die die Mapping-Praxis in OpenStreetMap für einen solchen Prozess darstellt.

* Wurzeln der Straßenauswertung: aufgegebene Auswertungen von Florian Lohoff und Sven Anders. * Aufbau des Systems und aktueller Bestand an Straßenlisten; einige Zahlen zum Datenumfang. * OSM-Lizenzumstellung 2012: damalige Auswirkungen; Auswirkungen bis heute? * Aktuelle Straßennamen-Abdeckung und historische OSM-Entwicklung bis heute, auf Basis der vollen historischen OSM-Daten. * Ursprung der Straßenlisten und zeitliche Entwicklung vor und nach Verfügbarkeit einer Straßenliste. * Verfügbare OpenData Dienste, die zur Erfassung von Straßennamen herangezogen werden könnten. Und sollten? * Mittel, um OSM-Mapper zur Erfassung zu motivieren.

Was das Revertieren unerwünschter Edits betrifft, so steckt OpenStreetMap noch in den Kinderschuhen. Wo die Wikipedia schon seit Urzeiten eine Revertierung von Spam oder Vandalismus per Mausklick ermöglicht, da verheddert man sich bei OpenStreetMap mit seinen vielen gegenseitigen Abhängigkeiten im Datenmodell ganz schnell in einem Dickicht - und das schlimmste ist, dass alles, was beim beim Reparaturversuch vorübergehend kaputtmacht, auch noch auf alle Zeiten gut sichtbar in der Historie dokumentiert ist. Frederik Ramm kann davon ein Lied singen und behandelt in diesem Vortrag eingehend die Ursachen für die Komplexität von Reverts in OpenStreetMap. Verschiedene häufige Szenarien werden vorgestellt und Strategien zur ihrer Bereinigung diskutiert. Dabei kommen die existierenden (Perl-)Skripte zur Anwendung, aber der Vortrag richtet sich durchaus auch an Programmierer, die auf diesem wichtigen Gebiet an eigenen Lösungen basteln möchten.

Die OpenStreetMap-Community treibt aus mehreren Gründen das Problem um, Änderungen verfolgen und ggf. rückgängig machen zu können. Verglichen wird dies gerne mit der Rückgängig-Funktion in der MediaWiki-Software. Da OpenStreetMap aber nicht aus einzelnen Dokumenten besteht, sondern eine zusammenhängende Datenbank bildet, gibt es bis heute kein überzeugendes Konzept dazu, wie ein Ausschnitt rückgängig gemacht werden kann. In diesem Vortrag werden wir zunächst anhand historischer Mapping-Unfälle ausleuchten, welchen Bedarf es realistischerweise für Änderungsverfolgung gibt und welche Einheiten von Daten man gerne rückgängig gemacht hätte oder hat. Dies mündet in einem Konzept, wie ein bequemes Tool zum rückgängig machen funktionieren müsste. Im zweiten Teil des Vortrages werden wir dann die neue Funktionalität der Overpass API vorstellen und erläutern, welchen Teil des zuvor skizzierten Tools sie abdeckt.

In den letzten Jahren entwickelten sich zahlreiche Open Source Projekte für die Darstellung von 3D-Globen und 3D-Daten im Web. Die Standardisierung von Webservices, Datenformaten und Darstellungsmodellen ist daher ein sehr aktuelles Thema. Inbesondere sind sowohl auf OGC- wie auch auf W3C-Seite Bemühungen dazu im Gange. Das OGC hat ein Entwurfskantidat für 3D Webservices, W3DS, publiziert. Der ISO X3D Standard schlägt ein XML-basiertes Dateiformat für die Speicherung von 3D-Grafiken vor und das W3C überlegt sich, X3D-Rendering in HTML5 zu integrieren. Andere Projekte implementieren ihre eigenen Webservices und Formate. Auf der Anwendungsseite unterstützt GeoServer W3DS und X3D, die X3DOM Programmbibliothek schlägt eine mögliche Implementierung von X3D in HTML5 vor und nicht zuletzt erlauben WebGL-kompatible Browser die Darstellung der 3D-Daten auf der Client-Seite. Die OpenLayers Community arbeitet auf eine interoperable and performente WebGL Darstellung um 4D Daten im Kombination mit Cesium Virtual Globe darzustellen und zu animieren. Die Präsentation wird die erwähnten Elemente weiter ausführen, einige Beispiele der spannensten Implenentationen vorführen und einen möglichen Weg zu einem 3D-Web für die Open Source GIS-Community aufzeigen.

Geologische Untersuchungskampagnen aus den Jahren 1950 bis 1980 auf dem Flächengebiet des Bundeslands Brandenburg haben einen gewaltigen Fundus an geologischen Fachinformationen hervorgebracht. In dem Projekt Brandenburg 3D (kurz: B3D) wurde auf Grundlage dieser Tiefbohrungen und geologischen Schnitte ein dreidimensionales Untergrundmodell bestehend aus Schichtgrenzen, Störungszonen und Salzstöcken modelliert. Um die Ergebnisse des Projekts an zentraler Stelle zu veröffentlichen und ohne fachspezifische Software zugänglich zu machen, wurde eine kombinierte WebGIS-Architektur entwickelt, die es erlaubt sowohl die vorhandenen zwei- als auch dreidimensionalen Daten über den Browser abzurufen. Zu den hier eingesetzten Komponenten zählen OpenLayers, GeoExt 2, Ext JS 4, X3DOM, PostGIS 2 und GeoServer. Alle Daten zu Bohrungen, Tiefenprofilen und geologischen Verbreitungsflächen wurden aufbereitet, in einer PostGreSQL/PostGIS Datenbank abgelegt und über den GeoServer publiziert. Für die 3D-Daten kam hierbei der W3DS (Web 3D Service) zum Einsatz, der die Daten als Szenengraph liefert und clientsetig eine volle Interaktion und Navigation ermöglicht. Die Basis für den 3D-Client ist das Framework X3DOM, welches im Rahmen des Projekts über eine eigene Bibliothek mit Ext JS verbunden wurde, sodass eine einfache Kommunikation zwischen diesen stattfinden kann. Das entwickelte WebGIS basiert rein auf JavaScript und es besteht damit keine Notwendigkeit von Browser-Plugins. Dieser Vortrag präsentiert die technischen Grundlagen der eingesetzten Architektur mit einem Fokus auf die 3D-Visualisierung und die hierauf aufbauenden Client-Funktionalitäten, z.B. das Generieren virtueller Profilschnitte an beliebiger Stelle des Untergrundmodells.

Die 3D City Database (3DCityDB) wurde auf der letzten FOSSGIS in Rapperswil vorgestellt. Es handelt sich dabei um eine freie Datenbanklösung, mit der CityGML-basierte 3D Stadtmodelle in Oracle Spatial oder PostgreSQL/PostGIS gespeichert werden können. Über eine Java-Applikation können CityGML Dokumente beliebiger Größe in die Datenbank geschrieben und auch wieder in Dateien exportiert werden. Für das nächste Frühjahr ist mit Version 3.0 ein neuer Major-Release für die 3DCityDB geplant. Neben der vollen Unterstützung von CityGML 2.0.0 (u.a. Brücken, Tunnel) wird die Datenbank auch über einen Web Feature Service 2.0 ansprechbar sein. Das vereinfacht die Einbindung der 3DCityDB in eine Geodateninfrastruktur. Die Filtermöglichkeiten eines WFS (gemäß dem OGC Filter Encoding Standard) werden ebenfalls in den Teilmodulen des Importer/Exporter umgesetzt, damit z.B. viel präzisere Objektexporte aus der Datenbank möglich sind. Die 3DCityDB wird wie viele andere Open-Source-Projekte ab sofort auf GitHub weiterentwickelt. Die bisher parallel entwickelten Importer/Exporter-Versionen für Oracle und PostgreSQL werden in einer gemeinsame Schnittstelle aufgehen, so dass eine Unterstützung weiterer Datenbanksysteme leichter umzusetzen wäre. Der Vortrag wird dieses Mal einige Features live vorführen. Wer sich für die Hintergründe des Projektes und technische Details der Software interessiert, dem sei das Abstract und die Slides von meinem Vortrag auf der FOSSGIS 2013 (http://www.fossgis.de/konferenz/2013/programm/events/588.de.html) bzw. ein Besuch auf der Homepage der 3DCityDB (www.3dcitydb.net) empfohlen.

As the amount of scientific data continues to grow, researchers need new tools to help them visualize complex data. Immersive data-visualisations are helpful, yet fail to provide tactile feedback and sensory feedback on spatial orientation, as provided from tangible objects. The gap in sensory feedback from virtual objects leads to the development of tangible representations of geospatial information to solve real world problems. Examples are animated globes, interactive environments like tangible GIS, and on demand 3D prints. The production of a tangible representation of a scientific data set is one step in a line of scientific thinking, leading from the physical world into scientific reasoning and back: The process starts with a physical observation, or from a data stream generated by an environmental sensor. This data stream is turned into a geo-referenced data set. This data is turned into a volume representation which is converted into command sequences for the printing device, leading to the creation of a 3D printout. As a last, but crucial step, this new object has to be documented and linked to the associated metadata, and curated in long term repositories to preserve its scientific meaning and context. The workflow to produce tangible 3D data-prints from science data at the German Research Centre for Geosciences (GFZ) was implemented as a software based on the Free and Open Source Geoinformatics tools GRASS GIS and Paraview. The workflow was successfully validated in various application scenarios at GFZ using a RapMan printer to create 3D specimens of elevation models, geological underground models, ice penetrating radar soundings for planetology, and space time stacks for Tsunami model quality assessment. While these first pilot applications have demonstrated the feasibility of the overall approach, current research focuses on the provision of the workflow as Software as a Service (SAAS), thematic generalisation of information content and long term curation.

Bei der RoboCup Rescue Simulation League handelt es sich um einen Wettbewerb, bei dem Teams von Software-Agenten die Folgen einer simulierten Katastrophe in einer Großstadt bewältigen müssen. Simulierte Ambulanzen, Feuerwehren und Räumtrupps müssen dabei Brände unter Kontrolle halten und Verschüttete retten, was durch begrenzte Sicht und Kommunikation erschwert wird. Die Simulationsliga dient zwei unterschiedlichen Zwecken: Zum einen der Erforschung heterogener Multi-Agentensysteme, zum anderen der Entwicklung realistischer Simulatoren und Systeme die bei der Bewältigung solcher Katastrophen hilfreich sein können. Das Simulationssystem wird im Rahmen eines Open-Source-Projekts weiterentwickelt. Realistische Stadtkarten sind dabei für die Simulation enorm wichtig. Lange Zeit waren offizielle GIS-Daten die einzige Möglichkeit, realistische Karten für die Simulation League zu erzeugen. Solche Daten waren jedoch nur begrenzt verfügbar, und restriktive Lizenzbedingungen hätten es zum Teil unmöglich gemacht, die resultierenden Rescue-Karten frei zu veröffentlichen. Daher ist OpenStreetMap eine ideale Datenquelle für die Liga: So gut wie jede größere Stadt (und viele kleinere Städte) sind detailliert gemappt, die Daten sind unter einer freien Lizenz verfügbar in einem weltweit einheitlichen Format verfügbar. Dieser Vortrag stellt die RoboCup Rescue Simulation League vor, beschreibt die Unterscheide und Gemeinsamkeiten zwischen den verwendeten Datenmodellen und denen von OpenStreetMap und die Herausforderungen die bei der Konvertierung zwischen den Formaten auftraten.

Die deutsche OpenStreetMap-Karte zeigt es auf den ersten Blick: In vielen Städten gibt es lokale Stammtische und Mappertreffen. So sehr OSM auch auf moderne Browsertechnologien, Crowdsourcing und "soziale" Features in der Website setzt: Ein wichtiges Standbein der Community bleiben die lokalen Treffen von Mapping-Enthusiasten. In Niederbayern gibt es gleich zwei aktive Stammtische – in Passau und Landshut – die zudem vierteljährlich ein niederbayernweites Treffen ausrichten. Diese persönlichen Begegnungen sind wichtig, sie ermutigen die Anwesenden sich weiterhin zu beteiligen, informieren über Neuigkeiten und führen vor allem zur Planung neuer Projekte und Aktionen. In diesem Vortrag stellen Mapper aus Niederbayern viele der Aktivitäten aus erster Hand vor. Sie berichten von Erfahrungen mit der Zusammenarbeit zwischen Community und Behörden, den vielseitigen OSM-Projekten der Passauer Universität, der Arbeit mit Presse und Öffentlichkeit und nicht zuletzt den Fortschritten bei der Kartographierung Niederbayerns. Angesichts der Vielzahl interessanter und informativer Themen dürfte jeder Zuhörer die eine oder andere Anregung vom Vortrag mit nach Hause nehmen. Und vielleicht gibt das ja den Anstoß, selbst zum regelmäßigen Besucher eines lokalen Treffens zu werden – oder sogar eines zu gründen.

Die Erhebung und Verarbeitung von Geodaten wirft eine Reihe von datenschutzrechtlichen Fragen auf. Auch in der Rechtswissenschaft herrscht bei der Beurteilung große Unsicherheit. So ist es bereits mit Schwierigkeiten verbunden, eine verlässliche Aussage darüber zu treffen, ob und wann ein geographisches Datum gleichzeitig ein personenbezogenes Datum darstellen. Der Beitrag analysiert zunächst die Voraussetzungen, wann personenbezogene Daten im Sinne des Bundesdatenschutzgesetzes vorliegen. Sodann wird diese Problematik auf den Bereich von Geodaten bezogen. Am Ende des Beitrags werden Kriterien herausgearbeitet, die es ermöglichen, problematische Geodaten zu identifizieren. Der Vortrag richtet sich sowohl an Mitwirkende des Open Street Map Projektes als Erfasser von Geodaten als auch an Verwender von Geoinformationssystemen als Verarbeiter von Geodaten.

Open Data und Selbstorganisation Urbanistische Interventionen und bottom-up grassroots mapping im Lichte kollaborativer Aktionsforschung. Public Space Invaders und die Berliner Gartenkarte setzen sich beide auf ihre Weise mit dem öffentlichen Stadtraum auseinander: Auf der einen Seite stehen Selbstorganisationsprozesse temorärer architektonischer Interventionen, auf der anderen die Visualisierung der Verteilung von Projekten der Urbanen Landwirtschaft in Berlin. Vermittelt werden beide Aspekte durch die ausschließliche Verwendung von Open Source Software und einer medientheoretischen Betrachtung der Prozesse als "Organisierte Netzwerke". Nicht nur flache Hierarchien der Selbstverwaltung oder dezentrale Kommunikationsstrukturen zeichnen diese Vorgänge empirisch aus, sondern auch ein Bekenntnis zur legalen Ausreizung des Urheberrechts zur Schaffung einer Wissensallmende. Die Lizenzierung von Daten und Source Code ermöglicht demnach neue Handlungsformen, die erst langsam in der Allgemeinheit Anerkennung finden. Leider führen Mischformen noch allzu häufig zu präkeren Arbeitsbeziehungen, da Kollaboration oftmals mit kostenloser Arbeit verwechselt wird. Nun stellen wir uns die Frage, wie in Realisierung der gemeinschaftlichen Zukunft unserer Gesellschaften Offene Daten und dezentrale Prozesse dem Gemeinwohl dienen werden. Daher liegt ein großes Augenmerk gegenwärtig auf der Sichtbarmachung bereits stattfindender Entwicklungen, um sie gemeinsam in einen größeren Kontext zu stellen. Ideellerweise helfen semantische Technologien dabei monistische Theorien durch ein Netz lokal definierter Ontologien zu ersetzen, um selbst die Epistemologie zu dezentralisieren. Wir arbeiten gemeinsam an der Schaffung neuer Sprachen der Selbstorganisation.

Mit OpenLayers 3 steht eine komplette Neuentwicklung der funktionsreichen OpenLayers-Bibliothek zur Verfügung. Die verbesserte Unterstützung mobiler Geräte war ein primäres Ziel der neuen Version. Dieser Vortrag stellt den JQuery Mobile basierten OL3 Mobile Viewer vor, der erweiterte Funktionen wie automatische Kartenausrichtung oder Positionsnachführung bietet. Es wird auch ein Vergleich mit anderen Viewern, wie der auf Bootstrap und AngularJS aufbauenden Neuentwicklung von Swisstopo angestellt.

Mapbender3 ist eine Software zur einfachen Erstellung von WebGIS Anwendungen. Basierend auf dem aktuellen Symfony2 Framework wurde eine moderne Webanwendung geschaffen, die durch das Baukastensystem der Bundles von Symfony2 einzeln als auch in andere Anwendungen integriert Verwendung finden kann. OpenLayer dient als Kartenanwendung und wird über MapQuery angesprochen. Zusammen mit einem modernen Verwaltungsbackend für die Kartenanwendungen ist Mapbender3 ein komfortables Werkzeug für die Erstellung und Pflege von Kartenanwendungen. Der Vortrag geht vor allem auf die neuen Komponenten in Mapbender3 ein und stellt diese vor. Einsteigern wird ebenfalls ein Überblick über die Software gegeben. Mit Mapbender3 können einfach WebAnwendungen über ein paar Klicks im Administrations-Backend erstellt werden. Das Administrations-Backend beinhaltet außerdem die Möglichkeit, ein Dienste-Repository aufzubauen. Dienste können hierbei verschiedene von OpenLayers unterstützte Quellen sein. Mapbender3 bietet eine Benutzer- und Gruppenverwaltung mit der Möglichkeit Rechte zuzuweisen. Rechteverwaltung. Benutzer können auch über LDAP in Mapbender übernommen werden. Eine Sicherung von Diensten über OWSPROXY ist ebenfalls vorhanden.

Vaadin ist als Framework in der WebMapping Szene noch sehr unverbreitet. Trotzdem bietet Vaadin einige Konzepte und Technologien, welche es besonders attraktiv für einen produktiven Einsatz macht. Vaadin als Framework ermöglicht es während der Entwicklung sich auf eine Technologie zu konzentrieren. Die gesamte Programmierung geschieht in Java und ist wesentlich näher an der einer Desktopanwendung. Dieses Konzept merkt man auch durch den Komfort und die ansprechende visuelle Darstellung der mit Vaadin entwickelten Oberflächen. Im Gegensatz zu anderen Webframeworks setzt Vaadin auf nur eine Technologie und die Umsetzung der Server und Clientseite geschieht ‚automatisch‘. Der Entwickler muss sich somit weder um die Kommunikation von Browser und Server, noch um verschiedene Teillösungen kümmern. Die Ausführung erfolgt auf einem Apache Tomcat Server und im Frontend wird das bereits bekannte Google Web Toolkit (GWT) verwendet. Da sämtliche Aktionen eine serverseitige Datenvalidierung benötigen, ist die Sicherheit stets gewährleistet und böswillig manipulierte Client-Daten werden von Anfang an abgefangen. Das Widget vOpenLayers ist eine Wrapperklasse von OpenLayers für Vaadin, welche es grundsätzlich ermöglicht OpenLayers Funktionen zu nutzten. OpenLayers das weit bekannte und stets gepflegte Projekt, ist das ideale Framework für eine browserbasierte GIS Lösung. Mit vOpenLayers ist somit die ideale Schnittstelle zwischen Vaadin und der GIS Welt geschaffen worden. Dank Java als Programmiersprache ist die Entwicklung einer Webanwendung sehr einfach und unkompliziert. Durch die starke Verbindung zwischen den zwei Frameworks Vaadin und OpenLayers ist nun auch eine Bindung entstanden die Möglichkeiten im GIS Bereich öffnet.

Das MapFish Framework erlaubt es, funktional reiche WebGIS Applikationen einfach und auf flexible Art und Weise zu erstellen. Es kombiniert einige der besten Open Source Tools in einem Framework: OpenLayers 2, ExtJS3 und GeoExt4 auf der Client-Seite, und MapFish Print sowie Ruby oder Phython Module (insbesondere auf Pyramid basierend) auf der Server-Seite. Neben den auf OGC-Standards basierenden Webservices stellt das MapFish Protokoll den effizienten Austausch zwischen Client und Server sicher. Auf dieser Basis wurden komplexe und sehr performante Webmapping Anwendungen entwickelt. Eines der MapFish-Anwendungen wird in der Präsentation genauer vorgestellt, um die Möglichkeiten des MapFish Frameworks zu zeigen: GeoMapFish ist ein komplettes WebGIS mit einer breiten Palette an Tools und Konfigurationsoptionen. Seit seiner Entstehung erlaubt die Plugin-basierte Architektur eine individuelle Anpassung der Applikationen auf die spezifischen Anwendungsfälle. Die Präsentation gibt eine Übersicht des MapFish WebGIS Frameworks und zeigt dessen Möglichkeiten mit der GeoMapFish Implementierung.

GIS as a Service In immer mehr Bereichen entwickeln sich Geografische Informationssysteme (GIS) zu wichtigen Analysewerkzeugen. Bei interdisziplinären Arbeitsgruppen, die häufig organisationsübergreifend arbeiten, wird die Zusammenarbeit durch den Einsatz von proprietärer Software gehemmt. Für solche Kollaborationen sind zentrale GIS-Installationen, die vollständig auf Open Source Komponenten aufbauen, eine wichtige Voraussetzung um optimale Wirkungen zu erreichen. Am Beispiel von VeriSO, einem Softwarepaket zur Prüfung von amtlichen Vermessungsdaten, wird beispielhaft die Vorteile eines solchen Systems aufgezeigt. Im Kanton Bern arbeiten 20 private Büros, die die Daten der amtlichen Vermessung führen und manipulieren. Das kantonale Vermessungsamt ist für die Kontrolle und Freigabe dieser Daten verantwortlich. Insgesamt kommen 4 proprietäre GIS zum Einsatz. Eine echte Zusammenarbeit auf einem gemeinsamen GIS ist nicht möglich. Auf zwei Terminalservern wird nun 25 Benutzern der Zugriff auf die Prüfsoftware gewährt. Die eigentliche Anwendung besteht aus einer QGIS-PostGIS-Installation mit einem zusätzlichen Plugin zur Datenprüfung. Auf dem Ubuntu-Betriebsystem ist ein X2GO-Terminalserver installiert. Dieses Paket ist mittels KVM auf den Terminalservern virtualisiert. Die Klientensoftware ist portabel, so dass keine Installation auf den Klientsystemen notwendig ist. Stefan Ziegler Nikolaus Grässle

Wie gross ist die Fläche, die eine durchschnittliche Schweizer Person braucht, um sich zu ernähren? Wie könnte diese optimiert werden? Wo läge sie und wie gross wäre diese Fläche für die Bevölkerung einer bestimmten Agglomeration, wenn alle Nahrungsmittel lokal und in der Schweiz produziert würden? Es geht also um eine Visulisierung der für die Ernährung einer Region benötigten Fläche. Um diese Fragen zu beantworten, muss zuerst der Flächenbedarf einer Person für deren Ernährung ermittelt werden. Dabei sollen nur die Produkte, die in der Schweiz anbaubar sind, berücksichtigt werden. Die Berechnungen stützen sich auf die Erträge der jeweiligen landwirtschaftlichen Primärprodukte. Für die Zuteilung der Flächen auf die verfügbare landwirtschaftliche Nutzfläche wird ein auf Geodaten und Methoden der Geoinformatik beruhendes Berechnungsmodell entwickelt. Dieses basiert hauptsächlich auf den Daten der Arealstatistik. Die Flächen werden distanzabhängig zugeteilt, um die Transportdistanzen zu minimieren. Das Modell ist so konzipiert, dass es auch übertragbar auf andere Regionen ist. In einem weiteren Teil wird versucht die heutige Diät zu optimieren. Dabei steht der Flächenver-brauch im Mittelpunkt, aber auch ernährungsphysiologische Aspekte werden berücksichtigt. Es resultieren zwei unterschiedliche Szenarien. Mit dem entwickelten Modell können Karten generiert werden, welche darstellen, wie gross die Ernährungsfläche einer Agglomeration wäre und wie sich Veränderungen in der Diät auf diese auswirken. Mit den Karten können auch andere Aspekte aufgezeigt werden. Es wird sofort ersichtlich, warum Futtermittelimporte in der Schweiz nötig sind. Die gesamte Analyse einschliesslich der Visualisierung wurde mit Opensource Komponenten erstellt. Diese Arbeit zeigt anschaulich das Potenzial und die Kapazität von Opensource Software im GIS Bereich.

Für ein Forschungsvorhaben wurden von einer Vielzahl von Waldbesitzern aus ganz Deutschland Geo- und Sachinformationen zu nutzungsfreien Wäldern bereitgestellt. Diese umfangreiche Datengrundlage enthält detaillierte Informationen zu ca. 400.000 Hektar Waldfläche in etwa 90 verschiedenen Datenlieferungen. Hierbei lagen die einzelnen Lieferungen in einer z.T. sehr heterogenen Form vor. Die Haltung, Bearbeitung und Bereitstellung aller Daten wurde in der Datenbank PostgreSQL mit der Erweiterung PostGIS durchgeführt. Wesentliche Arbeitsschritte bezüglich der Geoinformationen waren die Transformation in ein einheitliches Koordinatensystem, eine Überlagerungsanalyse der einzelnen Datenlieferungen, die Abbildung von überregionalen Daten auf die Waldflächen und die Identifizierung von zusammenhängenden oder benachbarten Flächenkomplexen. Hierbei wurden eine Reihe von Funktionen (PL/pgSQL) geschrieben, die die Grundfunktionalitäten von PostGIS zu spezialisierten Werkzeugen kombinieren. Beispielsweise wurde für die Verschneidung der Waldflächen mit deutschlandweit vorliegenden sehr großen Daten wie dem Digitalen Landbedeckungsmodell DLM-DE Funktionen entwickelt, die quadrantenweise eine sukzessive Abarbeitung der Gesamtfläche der Bundesrepublik ermöglichen. Auf diese Weise konnte eine übermäßige Auslastung des Arbeitsspeichers vermieden werden. Die Realisierung des Projektes wurde möglich durch die Nutzung von OpenSource Werkzeugen. Die verwendeten Werkzeuge stellen eine professionelle und höchst aktuelle Arbeitsumgebung dar, welche in dieser Form als kostenpflichtige Variante keines Falls hätte hergestellt werden können. Hintergrund: Die Bundesregierung hat das Ziel formuliert bis zum Stichjahr 2020 5 % der Waldfläche in Deutschland einer natürlichen Entwicklung zu überlassen. Da bisher keine verlässliche Bilanzierungsgrundlage existierte, wurde vom Bundesministerium für Umwelt, Naturschutz und Reaktorsicherheit ein Vorhaben beauftragt, welches die entsprechende Grundlage erarbeitet. Das Vorhaben ist weitgehend abgeschlossen.

Bereits seit über einem Jahr ist im Kanton Basel-Landschaft das Web-GIS "GeoView BL" erfolgreich im Einsatz. Es besteht aus Open-Source-Komponenten und bietet damit eine unglaubliche Erweiterbarkeit. Auch dieses Jahr möchten wir einen Einblick aus Anwendersicht in den Umgang mit einer solchen Open-Source-Lösung bieten. Wir werden dabei hauptsächlich auf die Belange der Weiterentwicklung eingehen, da wir inzwischen recht erfolgreich Lösungen implementieren, die dann innerhalb des Kantons zum Einsatz kommen. Folgende Punkte werden behandelt: 1. Personeller Aufwand 2. Entwicklungsumgebung (welche Werkzeuge, welche Methoden, welche Philosophie) 3. Kleinlösungen oder generische Lösung? 4. Was lässt sich erreichen? (konkrete Eigenentwicklungen aus dem Kanton BL)

Das Projekt GDA Wasser wurde Ende des Jahres 2011 durch die Wasserwirtschaft Rheinland-Pfalz zur Ausschreibung gestellt. Ziel war es, eine moderne, umfassende GIS-Architektur auf OpenSource-Basis umzusetzen, um die bestehende, auf älteren Technologien beruhende GDI abzulösen. Aufbauend auf dem Vortag der FOSSGIS 2013 „Das SHOGun-WebGIS Framework“ von Till Adams wird in diesem Vortrag die praktische Anwendung der entwickelten Lösung im Rahmen des Projektes GDA Wasser dargestellt. Die im Projekt verwendete Architektur setzt sich im Wesentlichen aus einem soliden Backend, aufsetzend auf oben erwähntem SHOGun (Java EE, Kernkomponenten Hibernate, Spring3) und einem Verwaltungs- und GIS-Client unter anderem auf Basis der JavaScript Bibliotheken Ext JS, OpenLayers und GeoExt2 zusammen. Das Backend stellt folgende Kernfunktionalitäten bereit: Erstellung, Verwaltung und Editierung von GIS-Oberflächen inklusive Rechteverwaltung und Absicherung mittels Spring-Security sowie Anlegen und Verwalten von Kartendiensten. Dabei können Layer durch Hochladen von Geodaten in GeoServer angelegt und auch mit Tabellen, Zeitreihen und Bildern verknüpft werden. Das Frontend besteht neben dynamisch erzeugten GIS-Applikationen aus breit gefächerten Konfigurationsoberflächen. Ein Einsatzfeld der Architektur GDA Wasser ist die dynamische Erstellung und Konfiguration von thematischen Kartenanwendungen. Die Funktionalitäten einer solchen GIS-Applikation erstrecken sich über ein weites Feld: Von der reinen Anzeige spezifischer Themen, deren dynamischer grafischer Ausgestaltung, Anlage neuer Layer, Digitalisierungs- und Annotierungsfunktionen, über Druckfunktionen, individuelle Abfrage-, Such- und Selektionswerkzeuge, Exportfunktionalitäten und Speicherung von Arbeitsständen, um nur einen kleinen Teil zu nennen. Ebenfalls stehen Schnittstellen für externe Applikationen bzw. Fachanwendungen bereit, um eine Interaktion mit diesen zu gewährleisten. Der Vortrag soll einleitend einen kurzen architektonischen Überblick geben und die verwendeten Komponenten beleuchten. Ein Großteil des Vortrages soll sich auf die praktische Anwendung konzentrieren und zeigen, welche Funktionalitäten und Möglichkeiten durch das Gesamtsystem gegeben werden.

Dieser Beitrag beschäftigt sich damit, die Analyse von Social Media Daten als eine Art „Human Sensor“ in einem Sensor Observation Service (SOS) bereitzustellen. Hintergrund ist die Möglichkeit, welche die Analyse von Social Media Daten aus den unterschiedlichen Netzwerken, wie Twitter, Facebook, Flickr oder Youtube bietet. Vor allem im Bereich der Marketinganalyse und des Katastrophenmanagements wird dies ein immer häufiger genutztes Werkzeug. Die Relevanz des Raumbezugs bei Social Media zeigt der Prototyp einer Arbeit, welcher die Ergebnisse einer gefilterten Twitter-Suche über einfache kartographische Darstellungsformen räumlich visualisiert (http://tweetmap.fh-mainz.de). Durch den Einsatz von von Natural Language Processing (NLP), z.B. der Sentimental Analyse, können Social Media Daten hinsichtlich des Inhaltes untersucht werden. Aus diesen Untersuchungen lassen sich detailliertere Informationen, ähnlich zu physikalisch gemessenen Phänomenen gewinnen. Dadurch lassen sich Social Media Daten zu einem Human Sensor wandeln. Unter Human Sensors versteht man ein Messmodell, in dem Menschen neben physikalischen Messungen, wie z.B durch Fitnessarmbänder, auch subjektive „Messungen“ wie Sinneseindrücke, Empfindungen oder persönliche Beobachtungen beitragen (vgl. Resch et al1). Die Nutzung von Social Media basierten Human-Sensors gewinnt zudem an Bedeutung, wenn diese Daten in den Zusammenhang mit anderen Datenquellen, wie z.B. Umweltinformationen, gesetzt werden können. Eine Herausforderung dieser Zusammenführung ist die Interoperabilität zwischen den Daten. Diese kann durch den Einsatz von Standards erreicht werden. Der hier vorgestellt Ansatz basiert auf dem Sensor Observation Service (SOS) aus dem Bereich des Sensor Web Enablements (SWE). Die Kombination der oben genannten Bereiche (Raum/Zeit, NLP, Human Sensor) ergibt hierfür eine Sensordatenquelle in einem SOS-Netzwerk. In diesem Netzwerk können die so verwalteten Information mit anderen räumlichen Sensordaten kombiniert werden. Der Beitrag fokussiert dabei die Konzeption und Entwicklung eines Systems, welches die Möglichkeit bietet, Daten aus Social Media Netzwerken (zunächst beispielhaft mit Twitter) und deren Analyse (NLP), als Beobachtungen in einem Sensornetzwerk als SOS zur Verfügung zu stellen. Zudem werden Ansätze gezeigt die gesammelten Daten räumlich und zeitlich zu visualisieren. Das System basiert ausschließlich auf FOSS Komponenten, wie die aus der 52°North Sensor Web Community oder Projekten aus dem Spring Framework. *1: http://www.berndresch.com/download/work/publications/resch_et_al_people_as_sensors_agit2011.pdf

Praämbel: Angeregt durch den OSM-Podcast Nr. 24 wurde zwischen uns, Peter Körner und den anderen Anwesenden im Mumble-Chat ein kleines "Interview" zum Thema Opencaching abgehalten. Nach dem Interview war man sich einig, dass "wir" uns bei der FOSGISS mit einem Beitrag bewerben sollten und unser Hobby, unsere Plattform und die dabei verwendete Technik des OSM Kartenmaterials vorstellen sollten. Darüber hinaus stellte man fest, dass die so genannten "Mapping-Partys" themenbezogen auch gut als Event auf unserer Plattform gelistet und "organisiert" werden können. Ein früherer Versuch bei der Plattform geocaching.com schlug fehl, da die Nutzungsbedingungen ein solchen Event nicht zulassen würden. "Wir" als OpenSource-Projekt stehen dafür aber dahinter und möchten uns im Rahmen der FOSSGIS einmal vorstellen. Wir hoffen, dass unsere Einreichung, die erst kurzfristig zusammengestellt wurde, ausreicht, um das Interesse für einen Vortrag von uns zu wecken. Daher stellen wir hier, uns und unsere Bereiche, die wir anreißen wollen schon mal vor. Die FOSSGIS als Konferenz haben wir bislang leider nicht wahrgenommen und sind daher bemüht unseren Vortrag passend und interessant vorzubereiten. Geocaching Geocaching ist DIE Form der modernen Schatzsuche. Während man früher auf den Boden schaute um sich an Papierschnipsel o.ä. zu orientieren, läuft man heute auf der Suche nach dem "Schatz" mit einem GPS-Gerät durch Stadt und Land. Um etwas weiter auszuholen: Geocaching entstand im Jahr 2000 und wurde erst dadurch möglich, dass die USA die Genauigkeit des GPS-Signals für Jedermann deutlich verbesserte, wodurch es auch Privatpersonen möglich wurde, einen konkreten Punkt zielgenau zu finden. Am Ende der Suche steht fast immer ein verschieden großer Behälter, der immer ein Logbuch, in das sich der Finder einträgt, und je nach Größe noch weitere Gegenstände enthält. Die Größen variieren von Nano, einem sehr kleinen Behälter mit einem etwa centgroßen Durchmesser, bis sehr groß, was Tonnen, Fässer, oder noch größere Verstecke bezeichnet. Nachdem man den ersten versteckten Cache, der sich in Oregon, USA befand, heute als Traditional Cache bezeichnen würde, bei dem die Zielposition von vornherein angegeben ist, haben sich mit der Zeit verschiedene andere Arten von Caches entwickelt. So gibt es Mystery-Caches, bei denen meist im Vorfeld Rätsel zu lösen sind, um die Position des Cachebehälters zu ermitteln. Außerdem gibt es Multi-Caches, bei denen auf einer mehr oder weniger langen Wanderung verschiedene Stationen angelaufen werden müssen, an denen man die Koordinaten der nächsten Station entweder erhält oder errätseln muss. Eine Sonderform stellen virtuelle Caches dar, bei denen kein Behälter zu suchen ist, sondern meist Informationen eingeholt werden müssen, um ein Logpasswort zu ermitteln. Plattformen Natürlich haben sich in der Zeit auch verschiedene Plattformen entwickelt, die den Geocachern die Möglichkeit geben, die zu den Cache gehörenden Listings online zu erstellen. Als erstes war da die US-amerikanische Plattform Geocaching.com, auf der heute auch weltweit die meisten Caches gelistet sind. Ohne eine (kostenfreie) Anmeldung ist das Angebot nicht nutzbar. Für über die Grundfunktionen hinausgehende Features muss jedoch eine kostenpflichtige Mitgliedschaft abgeschlossen werden. Dem gegenüber stehen verschiedene weitere Plattformen, darunter speziell für den deutschsprachigen Raum Opencaching.de. Im Kern unterscheidet sich Opencaching.de zunächst dadurch von geocaching.com, dass den Besuchern/Nutzern der Plattform nahezu alle Dienste auch ohne eine Registrierung angeboten werden. So ist bspw. das Einsehen der Listings und auch der Download als aufbereitete Datei für das GPS-Gerät jedermann möglich. Lediglich für das Loggen der Caches sowie das Einstellen eigener Listings ist eine kostenfreie Registrierung notwendig, da hier nutzerbezogene Daten hinterlegt werden. Opencaching.de Opencaching.de entstand im Jahr 2005, zunächst als privates Projekt. Für die verschiedenen Aufgaben wie Entwicklung, Technik und Support bildeten sich Teams aus Freiwilligen. Die Plattform wurde von den Cachern gut angenommen. Schon nach drei Jahren war eine Anzahl von etwa 10.000 Listings verfügbar. Um die Plattform rechtlich auf sichere Beine zu stellen übernahm Ende 2006 die Deutsche Wanderjugend (DWJ) die Betreiberschaft. Außerdem stellte die DWJ auch finanzielle Mittel zur Weiterentwicklung und für den Betrieb bereit. Die Deutsche Wanderjugend betrieb zu diesem Zeitpunkt bereits die Infoplattform Geocaching.de. Etwa 5 Jahre später, im November 2011, war es dann soweit, dass Opencaching.de wieder auf eigene Beine gestellt werden sollte, um die Entwicklung voranzutreiben und einige andere notwendige Vorhaben umzusetzen. Es begann eine Phase, in der intern ausgelotet wurde, wer aus dem alten Team auch in Zukunft dabei sein würde. Anschließend wurde der Community das Vorhaben vorgestellt und auch dort nach neuen Unterstützern gesucht. Zeitgleich begann auch die Suche nach einer geeigneten Rechtsform. Nach einiger Zeit formte sich dann das neue Team und der Verein kristallisierte sich als optimale Rechtsform heraus. Im Mai 2012 gründeten dann 15 Cacher den Verein Opencaching Deutschland e.V., der seitdem die Website betreibt. Wieder formierten sich neue Teams aus Freiwilligen, die seitdem für den laufenden Betrieb und die Weiterentwicklung des Webangebots sorgen. Seitdem hatte der Verein Zulauf und zählt derzeit 26 Mitglieder. Für die Mitarbeit an der Plattform ist die Vereinsmitgliedschaft aber keine Pflicht. Daher arbeiten an der Plattform auch zahlreiche weitere Helfer mit, die jedoch nicht Vereinsmitglieder sind. Aufgabengebiete sind unter anderem der User-Support oder die Erweiterung des Wikis. Besonders wichtig sind allerdings die Bereiche Systemadministration und Softwareentwicklung, schon allein weil sie den Kern des Plattformbetriebes darstellen. Wie bei vielen Communityprojekten bestehen hier die meisten Engpässe, weshalb Opencaching.de immer auf der Suche nach ambitionierten PHP-Entwicklern ist. Neben der Umsetzung der von der Community gewünschten Funktionen haben Entwickler bei Opencaching.de sehr viele Freiheiten um auch eigene Ideen zu verwirklichen. Opencaching.de ist Teil des Internationalen Opencaching-Netzwerkes. So werden weltweit noch 7 weitere Opencaching-Knoten in Europa und Nordamerika betrieben. Ein japanischer Knoten stellte nach dem Tōhoku-Erdbeben 2011 seinen Betrieb ein. Besonders nennenswert ist der Erfolg des polnischen Knotens, der in Polen mit großem Abstand Marktführer ist. Sowohl die spanische als auch die italienische Opencaching-Plattform sind in die deutsche Plattform integriert und greifen auf dieselbe Datenbank zurück. Durch die komplette Übersetzung in diese drei Sprachen sowie in die englische Sprache erreicht Opencaching.de einen erweiterten Nutzerkreis außerhalb Deutschlands. Alle diese Plattformen sind aus früheren Versionen des Quellcodes von Opencaching.de entstanden, mittlerweile haben sich die Quelltexte aber in zwei wesentliche Zweige auseinanderentwickelt. OpenSource Nach der Übernahme der Betreiberschaft durch den Verein wurde das open durch verschiedene Maßnahmen noch weiter vorangetrieben. So wurde etwa beschlossen, Diskussionen im Forum, soweit möglich, komplett öffentlich zu führen. Der wohl wichtigste Schritt war aber die komplette Offenlegung des Quellcodes auf GitHub und damit verbunden, die Neulizenzierung des Quellcodes unter GNU GPL. In diesem Rahmen erfolgte auch die schon lange geplante Lizenzierung aller Inhalte unter CC BY-NC-ND 3.0. Insgesamt war die Neulizenzierung nur der letzte logische Schritt, nachdem Opencaching.de selbst komplett frei nutzbar war und viel Opensource-Software Verwendung findet. So kommt bspw. als Templatesystem Smarty zum Einsatz, das unter LGPL lizenziert ist. Aber auch das wichtigste visuelle Werkzeug innerhalb der Listingplattform, die Geocachekarte, die Anfang 2013 eine vollständige Überarbeitung erfahren hat, sei hier zu nennen. Wo bisher auf Google Maps gesetzt wurde, steht nun das Kartenmaterial von OpenStreetMap an erster Stelle (erwähnt im OSM Podcast 16 - "Flopps tolle Karte"), einerseits weil die OSM als freies Communityprojekt vom Wesen her ähnlich ist, andererseits aber auch, weil viele Geocacher die Trackaufzeichnungen ihrer Cachetouren sowie ihre Ortskenntnis dafür nutzen, das Kartenmaterial von OpenStreetMap mit eigenen Beiträgen zu ergänzen oder zu vervollständigen. Gerade in entlegenen Gegenden, in touristisch weniger erschlossenen Bereichen stellt man als Geocacher immer wieder fest, das zumindest der "Weg zur Dose" eingezeichnet ist, ein deutliches Zeichen für den "Datenrücklauf" zum OpenStreetMap-Projekt. Unterstützung der Mapping-Partys Aus dem Podcast Team heraus wurden wir angesprochen, ob man die Mapping-Partys nicht bei Opencaching.de listen kann um hier die Kommunikation und Organisation zu vereinfachen. Gerne stehen wir mit der Plattform bereit und bieten diese Möglichkeiten. Denn auch interessierte Cacher, die durch ihre Wanderschaften in entlegenden Gebieten Wege/Daten sammeln könnten sich anschließen um zu erfahren wie man neue Pfade in die richtigen Kanäle steckt. Eine Synergie, in der zwei Plattformen interagieren und sich unterstützen können. Wir freuen uns auf die Teilnahme und sagen wie bei uns üblich "bis bald - im Wald!"...

Virtuelle Integration von Datenquellen mit einer Graph-Datenbank Prof. Dr. Petra Sauer, Dipl. Inf. Frank Herrmann, B.Sc. Jan Matusewicz Das gemeinsame Forschungsprojekt ArcoFaMa der Beuth Hochschule für Technik Berlin und der Hochschule für Technik und Wirtschaft Berlin schlägt einen Bogen über die Fachgebiete Datenbanksysteme, Geoinformation und Facility Management (FM). Zielstellung ist die Entwicklung einer Integrationsplattform für heterogene Datenquellen und -formate und deren Nutzung zur Integration von Datenbeständen des Projektpartners Botanischer Garten Berlin-Dahlem. Insbesondere Geodaten und FM-Fachdaten, die im operativen Einsatz üblicherweise in proprietären Datenhaltungssystemen getrennt behandelt werden, sollen integriert werden. Die Geodaten werden aus Vermessungsdaten des Außengeländes des Botanischen Gartens Berlin-Dahlem abgeleitet. Dazu werden die Vermessungsdaten in verschiedenen Arbeitsschritten extrahiert und semantisch angereichert, georeferenziert und in das CityGML-Format transformiert. Über die Integrationsplattform werden diese Daten u.a. mit Daten aus dem Facility Management verknüpft, die im IFC-Standard vorliegen. Die Integrationsplattform benutzt eine Graph-Datenbank als Metadatenspeicher. Durch das Knoten-Kanten-Datenmodell der Graph-Datenbank können sehr effizient vernetzte Strukturen abgebildet werden. Dies wird im Projekt für die virtuelle Integration der autonomen Datenquellen eingesetzt. Der Beitrag wird über den gewählten Ansatz zur Entwicklung der Integrationsplattform sowie die Besonderheiten des Datenmodells und die Transformationsschritte berichten sowie einen Einblick in das interdisziplinäre Forschungsprojekt geben.

Bei Apache CouchDB und Couchbase handelt es sich um sogenannte dokumentbasierte Datenbanken. Sie gehörten somit in die Kategorie der nicht-relationale Datenbanksysteme für die sich der Sammelbegriff „NoSQL“ eingebürgert hat. Eine Stärke von Apache CouchDB ist die (Multi-Master) Datenreplikation. Das bedeutet dass der Datenbestand verschiedener Datenbankinstanzen synchron gehalten werden kann, und dennoch Änderungen an beliebiger Stelle vorgenommen werden können. Die Replikation beschränkt sich nicht nur auf Apache CouchDB, sondern mittlerweile auf ein gesamtes Ökosystem. So ist es möglich Daten mittels HTML5-Technologie mit einem Browser zu synchronisieren. Diese stehen dem Anwender somit auch offline zur Verfügung, ohne dass eine Verbindung zu einem Server bestehen muss. Couchbase hingegen hat seine Stärke bei der Skalierung des Systems. So werden die Daten automatisch auf mehrere Rechner verteilt. Das nachträgliche Hinzufügen oder Entfernen von Rechnern ist über eine Web-Oberfläche sehr leicht möglich. Im Falle des Ausfalls eines Rechners läuft das System ohne Unterbrechung weiter. Couchbase bietet zudem Couchbase Lite an, dass eine Datenbank für Mobile Geräte darstellt. Dabei wird das Replikationsprotokoll von Apache CouchDB sowohl für Android als auch iOS implementiert. Somit ist es möglich Applikationen zu schreiben, die auch ohne ständige Internetverbindung funktionieren. GeoCouch bietet sowohl für Apache CouchDB als auch Couchbase eine Lösung um n-dimensionale Anfragen machen zu können. Es ist also nicht nur möglich räumlich Anfragen zu stellen, sondern weitere Eigenschaften wie z.B. Zeit, Größen oder beliebige andere numerische Werte mit einzubeziehen. In diesem Vortrag wird per Live-Coding gezeigt, wie leicht es ist eine Mobile Applikation zu Entwickeln, die die oben beschriebenen Technologien verwendet. Apache CouchDB, Couchbase, Couchbase Lite und GeoCouch sind Open-Source und stehen unter der Apache License Version 2.0.

Markus Schneider (schneider@m-click.aero) Deegree: AIXM WFS und WPS Services - GML Anwendungen im Aviation Bereich Um einen sicheren und geordneten Ablauf des Flugverkehrs zu gewährleisten, sind verlässliche Informationen zu den aktuellen Verkehrsbedingungen für alle Beteiligten, wie z.B. Piloten und Fluglotsen, von entscheidener Bedeutung. Für die Bereitstellung der aktuellen Informationen bezüglich Luftraumstruktur, Flugplätzen, Flugrouten und Flugsicherungsverfahren wird AIXM 5.1, der Standard für den weltweiten Austausch von aeronautischen Informationen, eingesetzt. Dieser Standard wurde gemeinsam von der FAA und EUROCONTROL in Form eines Applikation Schemas auf Basis von GML entwickelt (www.aixm.aero). Die Übertragung der AIXM Messages kann ähnlich wie bei den INSPIRE Download Services über das OGC WFS 2.0 Protokoll abgewickelt werden. Die Anforderungen an das GML Framework sind jedoch ungleich höher. Neben den komplexen Geometrie Objekten stellt insbesondere das AIXM Temporality Model, in dem die zeitliche Komponente der aeronautischen Information beschrieben wird, eine Herausforderung dar. In dem Vortrag wird gezeigt, wie eine erfolgreiche Umsetzung von AIXM WFS Services mit dem deegree Framework gelungen ist und wie sich mit der leistungsfähigen GML API die Verarbeitung von AIXM Daten problemlos gestaltet. Am Beispiel eines Spatial Processing Services und eines AIXM Business Rules Validators werden die professionellen Einsatzmöglichkeiten von AIXM Web Processing Services (WPS) mit dem deegree Framework demonstriert.

In vielen Bereichen hat sich Python als Allzweck-Programmiersprache etabliert – dies gilt auch für den Geo-Bereich. Von der Plugin Entwicklung, über automatisiertes Geoprocessing bis zu eigenständigen GIS Anwendungen ist für viele Entwickler Python das Tool der Wahl. Hierfür ist neben der Effizienz der Sprache sicherlich auch die große Auswahl an bestehenden Geo-Komponenten verantwortlich. Durch die einfache Integrierbarkeit von C und C++ Bibliotheken hat der Entwickler zudem Zugriff auf bewährte Komponenten wie GEOS, GDAL/OGR und Proj4. Der Vortrag zeigt auf, was Python als Programmiersprache attraktiv macht und wie es einem im Arbeitsalltag mit Geodaten das Leben einfacher machen kann. Es werden eine Vielzahl an Tools und Bibliotheken vorgestellt die mit Python verwendet, oder durch Python erweitert werden können. An kurzen Beispielen wird aufgezeigt, wie mit Python z.B. Geodaten aus einem Shapefile geladen, in Python verarbeitet und anschließend in eine PostGIS Datenbank importiert werden können.

Existierende Virtuelle Globen basieren auf gigantischen Geodatenmengen und erlauben die Integration eigener Inhalte, wie beispielsweise von 3D-Gebäudemodellen. Die Erweiterbarkeit dieser proprietären Software um eigene Geobasisdaten (z.B. verbesserte, hoch detaillierte Höhenmodelle) oder um eigene Funktionalität ist jedoch sehr eingeschränkt. Der quelloffene OpenWebGlobe (www.openwebglobe.org) ermöglicht die Realisierung massgeschneiderter, leistungsfähiger Virtueller Globen mit lokalen bis globalen Geodatensätzen und eigener Funktionalität. Der OpenWebGlobe Viewer basiert auf den neuen Web-Technologien HTML5 und WebGL ist daher in den meisten modernen Web-Browsern ohne vorgängige Installation eines Plugins lauffähig. Mithilfe von OpenWebGlobe wird eine Echtzeit 3D-Repräsentation von OpenStreetMap Daten auf einem Virtuellen Globus realisiert. Dabei wird direkt mit OSM Daten in der Postgres Datenbank gearbeitet. Die Resultate werden über 3D-Geometrie Tiles in einem JSON Format zurückgegeben. Dabei werden level of detail und caching-Strategien eingesetzt.

Die freie 3D-Renderingsoftware OSM2World bietet ihren Anwendern nun schon seit über 3 Jahren die Möglichkeit, die OpenStreetMap-Daten in einer ansprechenden dreidimensionalen Darstellung aufzubereiten. Allerdings haben sich sowohl das Projekt OpenStreetMap als auch die verfügbaren Technologien inzwischen weiterentwickelt. Immer detailreichere Daten wollen visualisiert werden, und neue Trends wie WebGL – eine Möglichkeit zur Hardwarebeschleunigten Darstellung dreidimensionaler Inhalte im Webbrowser – bieten neue Chancen, aber auch Herausforderungen. Gleichzeitig lässt das Thema 3D in OpenStreetMap allmählich seinen Nischendasein hinter sich und neue Anwendungsfelder entstehen. Wegen des steigenden Interesses steigen mittlerweile auch kommerzielle Anbieter mit proprietärer Software in das Themenfeld ein. Dieser Vortrag erzählt, wie OSM2World auf diese Entwicklungen reagiert. Der Besucher erfährt, was sich bei OSM2World im letzten Jahr getan hat, aber auch was die Zukunft bringen wird.

OpenStreetMaps Gebäudevisualisierung mit JavaScript Siehe angehängtes Dokument.