OpenStreetMap und Geoserver

Der Geoserver Blog zeigt, wie man OpenStreetMap-Daten mit Geoserver bereit stellen kann.

Das Tutorial beschreibt wie man die OSM-Format vorliegenden Daten in eine Postgres-Datenbank importiert und deren Visualisierung mit SLD beschreiben kann.

Kostenlose Luftbilder zum Download

Unearthed Outdoors bietet True Marble Images mit einer Auflösung von bis zu 250m unter einer Creative Commons Lizenz zum Download an. Die Bilder können kostenlos herunter geladen und bei Namensnennung weiter verarbeitet bzw. kopiert werden.

[via All Points Blog]

Links (01.12.2008)

Da ich in den letzten Tagen bei der LBS 2008 unterwegs war, war es hier im Blog ein wenig ruhiger. Deshalb gibt es jetzt hier die wichtigsten Links der letzten Wochen.

• Open Geospatial Data.
  Geoff Zeiss hat aktuelle Entwicklungen bei der Verfügbarkeit geographischer Daten und die Gründe dafür zusammengefasst und eine recht umfangreiche Sammlung freier Datenquellen dazu gegeben.
• Happier travels through Street View with Pegman.
  Das Interface von Google Maps wurde leicht überarbeitet und bietet einige Verbesserungen für Street View-Nutzer.
• Support for SQL Server.
  GeoServer bietet neuerdings auch eine Extension zur Anbindung von Microsoft SQL Server.

Ein mehr oder weniger umfangreicher Rückblick auf die LBS 2008 folgt natürlich bald.

Ein WMS für OpenStreetMap

Na endlich!

Die WhereGroup stellt OpenStreetMap-Daten als OGC-konformen Web Map Service bereit und ermöglicht damit erstmal eine relativ unkomplizierte Einbindung in eigene Projekte.

Das Ganze wird in drei Varianten angeboten. Ein Basic-Tarif ist kostenfrei, wird aber dafür nur zweimal im Jahr aktualisiert und eine Auswahl verschiedener Layer ist nicht möglich. Bei beiden Bezahltarifen wird täglich aktualisiert und man kann auch einzelnen Layer zur Darstellung auswählen.

Weitere Information gibt es bei der WhereGroup.

Das Geometriedatenmodell von GeoJSON

GeoJSON ist ein Datenformat zur Beschreibung geographischer Daten. Es ist eine Erweiterung der JavaScript Object Notation (kurz: JSON). Ähnlich XML handelt es sich um ein strukturiertes Datenformat, das ebenso einfach lesbar ist, aber wesentlich schlanker daher kommt.

Wie in allen vektorbasierten Datenmodellen ist die Grundeinheit ein so genanntes Feature, d.h. ein Objekt der realen Welt, das durch seine räumliche Verortung, seine Geometrie, und seine Eigenschaften oder Attribute beschrieben werden kann. Features, die der gleichen Art angehören, z.B. alle Straßen oder alle Eisenbahnlinien, können in einer so genannten FeatureCollection zusammen gefasst werden. Somit ist es mit GeoJSON möglich, mehrere Featuregruppen in einem Dokument abzubilden.

UML-Diagram des Geometriedatenmodells von GeoJSON.

GeoJSON orientiert sich an allgemein gültigen Prinzipien der geometrischen Beschreibung von Geodaten. Demnach können alle Objekte der realen Welt mit Hilfe von drei grundlegenden Geometrietypen abgebildet werden: Punkt, Linien und Fläche. Die kleinste Einheit ist dabei ein Punkt, der durch die Koordinaten in einem Bezugssystem beschrieben wird. Alle weiteren Geometrietypen bauen auf Punkten auf. Linien werden durch eine Folge von Punkten beschrieben. Flächen werden wiederum durch eine oder mehrere Linien beschrieben.

Die Position eines Punktes, oder Point, wird in GeoJSON durch ein Array aus zwei numerischen Werten beschrieben, die Rechts- und Hochwert abbilden.

Zur Beschreibung von Linien und Flächen werden in GeoJSON Array-Konstrukte verwendet. Eine Linie, in GeoJSON genannt LineString, wird durch ein Array aus Punkten dargestellt, die die einzelnen Knoten einer Linie darstellen. Eine Besonderheit ist dabei eine geschlossene Linie, ein so genannter LinearRing, bei der der Anfangs- und Endpunkt identisch sind.

Das LinearRing-Konstrukt wiederum wird zur Beschreibung von Polygonen, also Flächen, heran gezogen. Ein Polygon wird durch ein Array aus einem oder mehrerer LinearRings beschrieben. Ein LinearRing definiert dabei die Außengrenze eines Polygons. Durch weitere LinearRings können dann auch Inselflächen innerhalb eines Polygons geometrisch beschrieben werden.

Weiterhin können Features aus mehrere Geometrieobjekten bestehen. Es gibt daher MultiPoint-, MultiLineString- und MultiPolygon-Objekte, die mit einem Array aus Einzelobjekten des jeweiligen Typs dargestellt werden. Ein Anwendungsbeispiel wäre ein Gebäudekomplex, der aus mehreren einzelnen Häusern besteht, aber als ein Feature verwaltet wird.

Ein Sonderfall ist außerdem die GeometryCollection. In ihr können verschiedene Geometrietypen in einer Geometrie zusammen gefasst werden. Es handelt sich hierbei also um ein Array aus verschiedenen Geometrieobjekten.

OpenStreetMap und Standards

OpenStreetMap erfreut sich immer größerer Beliebtheit. Die Weltkarte, die nach dem Wiki-Prinzip verwaltet wird, bietet nicht nur freies Kartenmaterial an, sondern zählt aufgrund seiner zahlreichen Mitwirkenden auch zu den aktuellsten derzeit verfügbaren Datensätzen.

Doch die Nutzung dieser Daten in anderen Anwendungen gestaltet sich unter Umständen als schwierig, da die Daten nur in ungewöhnlichen Formaten exportierbar sind und deshalb nicht einfach in andere Anwendungen integrierbar sind.

Um OSM-Daten in beispielsweise einem Desktop-GIS weiterverwenden zu können, müssen die Daten momenten zunächst aus dem proprietären OSM-Format in standardkonforme beziehungsweise deFacto-Standardkonforme Formate (z.B. GML oder Shapefiles) umgewandelt werden. Statt sie z.B. mit XSLT zu transformieren, könnte man die Daten auch unmittelbar verwenden, wenn diese über einen Web Feature Service (WFS) bereit gestellt würden und im GML-Format ohne Umwege in ein GIS importiert werden könnten.

Ebenso können OSM-Karten nicht einfach in einem browser-basierten Client, wie OpenLayers, dargestellt werden. Prinzipiell ist das zwar möglich, indem man eine zusätzliche JavaScript-Bibliothek verwendet. Es ginge aber auch einfacher, wenn man die Daten über einen Web Map Service (WMS)- oder Web Feature Service (WFS) integrieren könnte. Darüber hinaus bestünde dann sogar die Möglichkeit, die Visualisierung an eigene Anforderungen anzupassen, indem man mittels Styled Layer Descriptor (SLD) Visualisierungsregeln an einen Map Service übermittelt.

Natürlich sind die hier aufgeführten Beispiele keine essenziellen Einschränkungen für die Funktion von OpenStreetMap. Aber die Bereitstellung von OSM-Daten über OGC-konforme Webservices würde nicht nur die Art und Weise der Datennutzung vereinfachen, sondern auch deren Reichweite erheblich erhöhen.

Projekte wie der OpenLS Route Service zeigen eindrucksvoll, welche Möglichkeiten für Daten- und Serviceintegration durch den konsequenten Einsatz von Standards entstehen.

Und gerade weil OpenStreetMap ein Paradebeispiel für die Übertragung des Open Source-Gedankens auf die Welt geographischer Daten ist, und somit insbesondere für Offenheit steht, könnte das Projekt auch dazu dienen, für die Vorteile der Nutzung von Standards zu werben.

GeoCommons Maker!

FortiusOne, die Frima, die hinter Geocommons steht, hat passend zum Finder!, mit dem man offene Geodaten finden und bereit stellen kann, eine neue Anwendung namens Maker! veröffentlicht.

Wie der Name impliziert kann man mit Maker! thematische Karten erstellen. Grundlage sind dafür die in Geocommons abgelegten Daten.

1: Geocommons Maker! MapBrewer

Im Mittelpunkt steht dabei der so genannte MapBrewer, ein Wizard, der den Anwender nach Auswahl eines Datensatzes schrittweise bei der Erstellung der Karte hilft. Zunächst wird die zu visualisierende Variable ausgewählt, dann erfolgt die Klassifizierung auf Basis verschiedener statistischer Parameter und schließlich werden Symbole und Farben festgelegt (Fig. 1). MapBrewer ist dabei so einfach angelegt, dass auch Nutzer mit geringen Kartographie- oder Statistikkenntnissen schnell zu guten Ergebnissen kommen. Es besteht außerdem die Möglichkeit, die Klassifizierung später manuell zu verfeinern, was vor allem kartographisch erfahrenen Nutzern entgegen kommen dürfte.

Darüber hinaus bietet Maker mit Straßenkarten, Satellitenbilder und Geländekarten von Google, Microsoft, Yahoo, OpenStreetMap und der NASA eine Fülle von Basislayern zur Auswahl.

2: Kartenanzeige in Google Earth

Die so erstellten Karten können über einen Permalink anderen Usern zugänglich gemacht werden oder als KML exportiert und z.B. in Google Earth angezeigt (Fig. 2) werden.

Wer außerdem eigene Daten in die Anwendung einfügen möchte, der kann diese in den Finder hochladen. Dabei werden Shapefiles, CSV mit Lat/Long-Koordinaten oder KML-Files akzeptiert.

Insgesamt gesehen, ist Maker! ein äußerst nützliches und hervorragend umgesetztes Tool, weil die Anwendung eine einfache und schnelle Erstellung thematischer Karten sowie deren Bereitstellung für Andere ermöglicht, ohne dass man dabei auf umfangreiche GIS-Software zurückgreifen muss.

Weitere Meinungen

• Sean Gorman (Off The Map/Fortius): Maker! Launched at Midnight – Giddy Up
• Stefan Geens (Ogle Earth): GeoCommons Maker!, Finder! launched
• Andrew Turner (High Earth Orbit): GeoCommons Maker! launches
• Adena Schutzberg (Directions Magazine): FortiusOne to Release GeoCommons Maker! Oct 1: Take Notice!
• The AnyGeo Blog: GeoCommons Maker! discover geospatial data and make your own maps

Wir brauchen freie Geodaten!

Großartige Präsentation zum Thema auf der FOSS4G.

OpenLS Route Service: Ein OGC-konformer Routenplaner mit OpenStreetMap-Daten

Die Cartography Research Group der Universität Bonn hat mit dem OpenLS Route Service einen web-basierten Routenplaner implementiert, der frei zugängliche Geodaten von OpenStreetMap verwendet, die darüber hinaus über OGC-konforme Services bereit gestellt werden.

Die Anwendung implementiert eine Reihe von OGC Spezifikationen. Besonders hervorzuheben ist dabei neben der Verwendung der OpenLS Spezifikation die Visualisierung aktueller Verkehrsinformationen, wie Staus und Baustellen, mit Hilfe eines Service Chains zwischen einem Sensor Observation Service, einem Web Processing Service und einem transaktionellem Web Feature Service.

Der Mehrwert von OpenLS Route Service könnte sicher noch erhöht werden, wenn die Straßendaten direkt von OpenStreetMap über einen standardkonformen Service abgerufen werden könnten. OpenStreetMap stellt seine Daten derzeit allerdings nur in einem proprietären Datenformat zur Verfügung, sodass die Daten über einen internen WFS bereit gestellt werden müssen. Dass kann unter umständen die Aktualität der Daten negativ beeinflussen.

Nichtsdestotrotz zeigt die Anwendung sehr gut die Möglichkeiten OGC-konformer Webservices in Verbindung mit Nutzergenerierten Geodaten für ein alltägliches Szenario.

Tiefgründigere Erläuterungen zum OpenLS Route Service können in einem Artikel von Alexander Zipf im Directions Magazine nachgelesen werden.

Heidelberg 3D

Mit Heidelberg 3D ist eines der ersten interaktiven 3D-Stadtinformationssysteme online gegangen. Die Anwendung ist eine der ersten Implementierungen des OGC Web 3D Service Discussion Papers. Darüber hinaus sind weitere Spezifikationen des OGC eingesetzt (u.a. WMS, WFS, WPS, Sensor Observation Service (SOS)); das System basiert damit vollständig auf offenen Standards.

Besonders interessant ist der Einsatz von Styled Layer Descriptor und Symbology Encoding für thematische Kartographie im Stadtmodell. Damit wird die Visualisierung von Daten verschiedener Services harmonisiert und außerdem die visuelle Veränderung über einen clientseitigen Editor ermöglicht.

Auf das Modell kann mit Hilfe des XNavigators, einem Java-basierten Client zugegriffen werden.

[via GIS Lounge]