Verschiedene Renderer und Technologien für die Darstellung von

Verschiedene Renderer und Technologien für die
Darstellung von Geodaten
Renderer
●
●
●
Rendern = (allg.) Darstellung oder Berechnung
von grafischen Inhalten
Für OSM existieren verschiedene Renderer, um
Geodaten zu visualisieren:
–
OSMarender
–
Mapnik
–
Geotools (u.a. benutzt von geoserver)
–
Kosmos
Renderer lassen sich i. A. nicht an den
produzierten Karten unterscheiden
–
... in der Regel aber schon
(Wdh.) Osmarender
(Wdh.) OSMarender
●
●
●
OSMarender ist ein Satz an XSLT-Regen für die
Erzeugung von SVG-Vektorkarten
SVG-Dateien können Beispielsweise im
Webbrowser oder (besser) mit Inkscape
betrachtet werden
Wie die Daten kartographisch dargestellt
werden, läßt sich selbst bestimmen
Rendern mit Osmarender
.osm
XSLTProzessor
.svg
SVGRenderer
.png
ZeichenRegeln
(Rules)
.xsl
Osmarender
OSMarender
●
●
Vorteile:
–
Plattformunabhängig
–
Setzt auf offene Standards (XML, XSLT)
–
Erzeugt Vektordaten
Nachteile:
–
Osmarender ist komplex und rechenaufwändig! ->
Nur für kleine ausschnitte geeignet
●
Lösung: Tiles@Home
Kosmos
Kosmos
●
OSM-Renderer für OSM-Benutzer
●
Leichtgewichtig
●
Interaktive Benutzung
●
Kein DB-Support
●
Nur Windows
●
Main-Feature:
–
Styles sind Wikiseiten, die automatische geparsed
werden (
http://wiki.openstreetmap.org/wiki/Kosmos_General_Purpose_Rules)
–
"democratize" rendering of OSM
Mapnik
Mapnik
●
●
●
●
Unabhängig von OSM entwickelt ->
Verwendung anderer Datenformate
Erzeugt ausschließlich Bitmaps
Für die Darstellung am Bildschirm konzipiert
(Hohe Auflösungen werden pixelig)
In C++ implementiert, daher schnell(er als
Osmarender)
Rendern mit Mapnik
.osm
osm2pgsql
PostGIS
osm.xml
Mapnik
.png
world_
boundaries
(Wdh.) PostGIS einrichten
Kommandozeile:
createdb osm
Sprachunterstützung
aktivieren
createlang plpgsql -d osm
psql osm -f lwpostgis.sql
psql osm -f spatial_ref_sys.sql
OSM-Daten direkt in DB importieren
●
Mapnik „versteht“ OSM-XML nicht direkt
●
Daten müssen in PostGIS-DB liegen
●
Das Tool osm2pgsql übernimmt den Import von
OSM-XML nach PostGIS
Import:
osm2pgsql -d osm daten.osm
●
●
Datenbank muss (z.Z.) lokal installiert sein
Worldboundaries
●
●
Problem: Küstenlinien und Ländergrenzen sind
nicht in der OSM-DB
Mapnik benötigt diese Informationen jedoch für
kleine Zoomstufen:
–
http://artem.dev.openstreetmap.org/files/world_boundaries.tar.bz2
–
Die Datei enthält Shapefiles.
Mapnik (für OSM) downloaden
Kommandozeile:
svn checkout http://svn.openstreetmap.org/
applications/rendering/mapnik
Subversion-Repository
Karte rendern mit Mapnik
●
Mapnik wird zum Großteil über
Umgebungsvariablen gesteuert
Kommandozeile:
Muß angepasst werden
(db, boundaries,
source ./set-mapnik-env
./customize-mapnik-map >$MAPNIK_MAP_FILE
./generate_tiles.py
./generate_image.py
Muß ebenf.
Angepasst werden
(Bbox, Zoom)
osm.xml
Mapnik-Tile-Server
●
●
●
●
●
Mapnik stellt neben einem Renderer auch einen
Tile-Server
Standard-Ansicht von OSM basiert auf einen
Mapnik-Tile-Server
Tiles sind „Kacheln“, die zu Karten
zusammengefügt werden
Tiles werden in einem Cache gespeichert,
damit nicht für jeden Request eine neue Karte
gerendert werden muss
Mapnik-Tiles: http://tile.openstreetmap.org/z/x/y
–
z = Zoom-Level; x,y = Tile-Koordinate
Aktualität
●
●
●
●
Wenn sich die Geodaten ändern, müssen ggf.
Tiles neu brechnet werden
Ausgelieferte Tiles werden neu berechnet,
wenn sie zum Zeitpunkt der Auslieferung älter
als 3 Tage sind
Wurden Tiles länger als 28 Tage nicht
ausgeliefert, wird zunächst ein leeres Tile
zurück gegeben („more OSM comming soon“)
Problem: Aktualität der Karten nicht sonderlich
hoch
Status-Abfrage
●
Mapnik-Tile-Status-Abfrage:
–
http://tile.openstreetmap.org/z/x/y.png/status
●
●
Z = Zoom-Level; x,y = Tile-Koordinate
Anforderung von Neuberechnung:
–
http://tile.openstreetmap.org/z/x/y.png/dirty
Tiles@Home
●
●
●
OSMarender ist langsam
Verteiltes Programm um Karten mittels
OSMarender zu erstellen
Verteilte Architektur:
–
1 Server, der Requests zum Rendern von Tiles
verteilt
–
X Clients, die ihre Rechenkapazität zur Verfügung
stellen, um die Tiles tatsächlich zu rendern und dem
Server zur Verfügung zu stellen
How it works
●
●
●
Wenn sich Daten in der OSM-DB ändern, wird
ein Request zum Re-Rendern des Tiles in eine
Warteschlange des T@H-Servicers eingereit
Clients arbeiten die Requests des Servers ab
und liefern ein Tile-Set (versch. Zoom-Stufen)
zurück, aus denen die Slippy Map erstellt wird
Üblicherweise dauert es 2-4 Stunden bis
änderungen in der DB sichtbar sind
Tile-Sets
●
●
●
●
Ein Render-Request wird immer für ein Tile in
Zoomstufe 12 formuliert
Ein Client liefert ein Tile-Set zurück
Ein Teil-Set besteht immer aus den Tiles der
Zoomstufen 12-17, also max. 1365 PNGDateien
(1 Tile auf ZS 12, 4 Teils auf ZS 13, 16 Teils auf
ZS 14, ... )
Zoomstufen
Zoomstufe Kacheln Kacheln kumul. Speicher Speicher kumul. Kachelbreite
0
1
1
5 kb
5 kb
40075 km
1
4
5
20 kb
25 kb
20038 km
2
16
21
80 kb
105 kb
10019 km
3
64
85
320 kb
425 kb
5009 km
4
256
341
1 mb
2 mb
2505 km
5
1024
1365
5 mb
7 mb
1252 km
6
4096
5641
20 mb
27 mb
626 km
7
16384
21845
82 mb
109 mb
313 km
8
65536
87381
328 mb
437 mb
157 km
9
262144
349525
1 gb
2 gb
78 km
10
1 Mio.
1 Mio.
5 gb
7 gb
39 km
11
4 Mio.
6 Mio.
21 gb
28 gb
20 km
12
17 Mio.
22 Mio.
84 gb
112 gb
10 km
13
67 Mio.
89 Mio.
336 gb
447 gb
5 km
14
268 Mio.
358 Mio.
1 tb
2 tb
2 km
15
1 Mrd.
1 Mrd.
5 tb
7 tb
1 km
16
4 Mrd.
6 Mrd.
12 tb
29 tb
611 m
17
17 Mrd.
23 Mrd.
86 tb
115 tb
305 m
18
69 Mrd.
92 Mrd.
344 tb
458 tb
152 m
Zoom-Level
●
●
●
●
(Ein Render-Requests an tah-Clients ist immer
Zoom-Level 12)
Zoom-Level 12 - 17 werden implizit immer
mitgerendert und als Tile-Set zum Server
gesendet
Zoom-Level 8 – 11 werden erstellt, in dem
reduzierte OSM-Daten (OsmXAPI) gerendert
werden
Zoomlevel 0 - 7 werden vom Server durch
Zusammenfassen aus den Tiles der vorherigen
Zoomlevel generiert
tah-API
●
Tiles abfragen:
–
http://tah.openstreetmap.org/Tiles/tile/z/x/y
●
●
z = Zoomlevel; x,y = Koordinaten der Kachel
Request senden:
–
http://tah.openstreetmap.org/Request/create/?x=1&y=2&priority=2
●
X,Y sind Tile-Bezeichner (Koordinate) mit Zoomlevel 12,
Priorität ist 2 ( Höchste Priorität 1, Neidrigste 3)
Manuelles Rendern
●
Fehler können es notwendig machen, ReRendering manuell anzustoßen:
–
http://informationfreeway.org
●
●
●
r = Re-Rendern
i = Informationen
Slippy-Map-Plugin (JOSM)
Anwendungen auf OSM
OpenCyclemap
Cyclemap-Key
OpenCycleMap
●
●
●
http://www.opencyclemap.org/
Internationale Karte für Fahrradfahrer,
basierend auf OSM-Daten
National Cycle Network cycle routes, other
regional and local routes,other cycling specific
features, such as:
–
Dedicated Cycle tracks and lanes
–
Bicycle parking
–
Contours and Hill Colouring
–
Bike shops
OpenCycleMap
●
●
●
OpenCycleMap nutzt Metainformationen von
Geodaten für Fahrradfahrer, um angepasste
Karten zu erstellen
Tagging-Schema für Fahrrad-Relevante
Geodaten:
http://wiki.openstreetmap.org/wiki/Cyclemap
=> Eigene Render-Rules und sorgfältiges
Tagging der Geodaten erlauben Erstellung von
Karten gemäß individueller Anforderungen
Openrouteservice
OpenRouteService
●
http://www.openrouteservice.org
●
Entwickelt von der Universität Bonn :-)
●
Routinganwendung auf Basis von OSMGeodaten
●
Fahrrad, Fußgänger und PKW-Routing
●
Zusätzlich:
–
–
POI-Suche (Wo ist die nächste Bank?)
Erreichbarkeitsanalyse
OpenRouteService
●
Vorraussetzung für OpenRouteService:
–
Korrektes und Vollständiges Tagging (Fahrradweg?)
–
Relationen (Einbahnstraßen, Abbiegevorschriften)
–
Korrekte Topologie (Überlappung statt Kreuzung?)
Openstreetbugs
OpenStreetBugs
●
●
http://openstreetbugs.appspot.com/
Neue Anwendung, um Fehler in OSM zu
markieren (mit der Hoffnung, dass sie jemand
fixed )