OpenStreetMap

Daniel Künne

Karten und Geodaten spielen eine wichtige Rolle in vielen populären Anwendungen und Webangeboten. Dabei werden die zugrundeliegenden Karten häufig um individuelle Daten, wie Anfahrtsbeschreibung oder Points of Interest, erweitert. Üblicherweise wird dabei die Basiskarte nicht selbst erstellt, sondern auf vorhandenes Material von Drittanbietern, wie GoogleMaps, zurückgegriffen. Diese Dienste stellen hierfür eine API zu Verfügung, die es dem Anwender ermöglicht punktgenau Marker oder andere Informationen auf der Karte hinzuzufügen.

Die Möglichkeiten, die sich bei der Verwendung eines solchen Dienstes bieten, sind jedoch beschränkt. So lässt sich weder die Farbgebung an den Webseitenstil anpassen, noch kann eine Auswahl getroffen werden welche Elemente überhaupt relevant sind und angezeigt werden sollen.

Einen anderen Ansatz verfolgt OpenStreetMap (OSM) : 2004 wurde OpenStreetMap von Steve Coast in Großbritannien mit dem Ziel der Erschaffung einer freien Weltkarte aus usergenerierten Inhalten gegründet, wobei "frei" nicht nur "kostenlos" meint. Vielmehr ist darunter "ohne urheberrechtliche Zugangsbeschränkung" und "ohne Relevanz-Beschränkung" zu verstehen. Dies wird deutlich, wenn man Kartenausschnitte von OpenStreetMap mit GoogleMaps vergleicht:

Abb. 1: Altstadt Osnabrück in OSM
Abb. 2: Altstadt Osnabrück in GoogleMaps

Wie die obigen Grafiken zeigen, kann der Unterschied lokal sehr groß sein. Auch wird deutlich, dass OpenStreetMap nicht nur Straßendaten sammelt, sondern auch Informationen zu Gebäuden und Umgebung bereitstellt. Da die Daten von Freiwilligen gesammelt werden, variiert der Detailgrad der Karten von Region zu Region. Während zum Beispiel Osnabrück zugute kommt, dass es ein regionales Projekt gibt, welches sich mit Erfassung der Geodaten innerhalb der Stadt befasst, sind in ländlichen Regionen die kommerziellen Kartensysteme überwiegend wesentlich besser.

Zugriff auf Kartendaten

Um auf die Daten von OpenStreetMap zuzugreifen und diese herunterzuladen, besteht neben einer API die Möglichkeit einen kompletten oder regional beschränkten Datenbankabzug des Datenbestandes zu erhalten. Die gesamten Daten, Planet-File genannt, erhält man direkt bei OpenStreetMap. Da diese Datei aber häufig zu umfangreich ist, bietet die Geofabrik GmbH Teile zum separaten Download an. Dieser Datenbestand umfasst dabei alle Länder Europas, sowie die Bundesländer Deutschlands.

Aufbau der Kartendaten

Sämtliche OpenStreetMap-Informationen bestehen aus den Objekttypen Nodes, Ways und Relations. Diese finden sich sowohl in den Datenbanktabellen als auch in den XML-Exports wieder.

  • Node: Ein Node symbolisiert einen Punkt mit seiner geographischen Koordinate, sowie allgemeinen Informationen zu Erfasser und Zeitpunkt des Erfassens. Er kann komplett alleine stehen, beispielsweise bei Parkbänken oder Verkehrsampeln, oder Bestandteil eines Weges sein.
  • Way: Ein Way ist eine geordnete Folge von Nodes, die auch mehrfach auf einem einzelnen Way liegen können. Flächen werden ebenfalls durch Ways dargestellt. Allerdings sind diese geschlossen, was dadurch ausgedrückt wird, dass Start- und Endpunkt identisch sind. Ways werden bei OpenStreetMap genutzt um Straßen, Flächen oder Gebäude darzustellen.
  • Relation: Eine Relation ist ein eine geordnete Folge beliebiger Objekte und dient zur logischen Verknüpfung verschiedener Einheiten. Im folgenden Ausschnitt eines XML-Exports fasst die Relation eine Kleingartensiedlung zusammen. Die einzelnen Member-Knoten stehen hier jeweils für einen Way, welcher wiederum vorher separat definiert ist und nur einen kleinen Bestandteil der gesamten Relation darstellt.

Was ein konkretes Objekt nun darstellt, ergibt sich aus seinen Attributen, den Tags. Diese sind Schlüssel-Wert-Paare aus Unicode-Zeichen wobei jeder Key pro Objekt nur einmal auftreten darf. Im Beispiel sieht man aber auch, dass Attribute weggelassen werden können, wenn sie nicht notwendig sind um ein Objekt zu beschreiben. Sind Nodes beispielsweise nur Bestandteil von Ways, so ist eine Attributierung unnötig.

<?xml version='1.0' encoding='UTF-8'?>
<osm version="0.6" generator="pbf2osm">
	<node id="125799" lat="53.0749606" lon="8.7867843" version="5" changeset="5922698"
		user="UScha" uid="45445" timestamp="2010-09-30T19:23:30Z" />
	<node id="125800" lat="53.0719347" lon="8.7840318" version="10" changeset="5923003"
		user="UScha" uid="45445" timestamp="2010-09-30T19:57:15Z" />
	<node id="125801" lat="53.0706761" lon="8.7819464" version="11" changeset="5922698"
		user="UScha" uid="45445" timestamp="2010-09-30T19:23:30Z" />
	[...]
	<way id="38834661" version="1" changeset="2100423" uid="59402" user="Mithi"
		timestamp="2009-08-10T18:29:38Z">
		<nd ref="457577162" />
		<nd ref="461056114" />
		<nd ref="461056117" />
		<tag k="highway" v="residential" />
		<tag k="name" v="Auf den Hohen Enden" />
	</way>
	[...]
	<relation id="33115" version="3" changeset="2022428" uid="55521" user="Ebbe73" 
		timestamp="2009-08-03T08:46:05Z">
		<member type="way" ref="27148028" role="inner" />
		<member type="way" ref="15400214" role="inner" />
		<member type="way" ref="23321484" role="outer" />
		<tag k="name" v="Kleingartenanlage" />
		<tag k="type" v="multipolygon" />
	</relation>
	[...]
</osm>
Ausschnitt aus einem XML-Export

Relevante Tags

Da der Server die Platzierung von Tresoren und Geschenkpaketen anhand der vorliegenden OSM-Daten vornimmt und sichergestellt sein muss, dass diese Positionen auch vom Spieler erreicht werden können, muss der Server Kenntniss über alle Tags haben, die eine solche Position beschreiben. In der aktuellen Version des Servers sind das 635 Schlüssel-Wert-Paare, die erreichbar und nicht gefährlich sind. So sind beispielsweise Knoten auf einer vierspurigen Autobahn erreichbar, aber sicherlich nicht als Zielpunkte in einem Spiel für Fussgänger zu wählen.

Bei der Frage welche Tags relevant sind, wurde entschieden Gebäude des öffentlichen Interesses, Naherholungsgebiete und Straßen bis zu einer bestimmten Größe zu berücksichtigen. Die Knoten, die direkt oder indirekt mit solchen Informationen verknüpft sind, werden in einer View herausgefiltert und der Verarbeitung durch den Server zugänglich gemacht.

Import der erreichbaren Knoten

Der Import der erreichbaren Knoten in ein neues Spiel besteht also insgesamt aus mehreren Schritten. Zuerst müssen die OpenStreetMap-Daten für das Bundesland, in dem gespielt werden soll, in das Datenbank-Schema osm_data importiert werden. Im Hintergrund werden diese Daten dann mit Hilfe einer View so aufbereitet, dass nur noch die relevanten Werte überbleiben. Da es sich bei diesen Werten zum einen noch nicht um geographische Objekte, sondern einfache double-Werte handelt, und zum anderen diese Informationen noch im falschen Datenbank-Schema liegen, wird eine SQL-Funktion genutzt, die im Hintergrund die endgültige Aufbereitung vornimmt.

CREATE OR REPLACE FUNCTION pgsgame.import_osmnodes(
		"min_lat" double precision, "max_lat" double precision, 
		"min_lng" double precision, "max_lng" double precision) RETURNS VOID AS $$
	DECLARE 
		start_id INTEGER; 
		end_id INTEGER;
	BEGIN
		SELECT INTO start_id max(id) FROM pgsgame.nodes;
 		IF start_id IS NULL THEN
			SELECT INTO start_id 0;
		END IF;
 
		-- Verbindung auf ein anderes DB-Schema
		PERFORM dblink_connect_u('myconn', 'dbname=osm_data');
 
		-- Ermitteln der relevanten Koordinaten, Erzeugen von Punkt-Objekten
		INSERT INTO pgsgame.nodes(id, version, coordinate) 
			SELECT 
				nextval('nodes_id_seq'), 1, 
				GeometryFromText ('POINT(' || lon || ' ' || lat || ')', 4326) 
			FROM dblink('myconn', 
				'SELECT DISTINCT lon, lat 
				 FROM export_nodes 
				 WHERE lat>' || min_lat || ' AND lat<' || max_lat || 
				' AND lon> ' || min_lng || ' AND lon<' || max_lng || ''
			) AS t(lon DOUBLE PRECISION, lat DOUBLE PRECISION);
		SELECT INTO end_id max(id) + 1 FROM pgsgame.nodes;
 
		-- Anpassen der neuen ID's
		INSERT INTO pgsgame.osmnodes(id) 
			SELECT id FROM pgsgame.nodes WHERE id > start_id AND end_id > id;
	END;
$$ language 'plpgsql';
Funktion zum Importieren der erreichbaren Knoten

Die obige Funktion erwartet vier Parameter mit denen angegeben werden muss, für welchen geographischen Bereich die Aufbereitung erfolgen soll. Anschließend werden anhand der vorliegenden Informationen Points generiert und in der Tabelle nodes eingefügt. Um eine korrekte Vererbung innerhalb des ORMs sicherzustellen, müssen die IDs der so erzeugten Punkte zusätzlich noch in die Tabelle osmnodes eingefügt werden. (siehe auch: Entity-Relationship-Modell)

Nach Ablauf dieser Funktion können Spiele in dem aufbereiteten Bereich gespielt werden, da der Server nun weiß, wo er sinnvoll Tresore und Geschenkpakete platzieren kann.


Page last modified on March 21, 2011, at 04:29 PM