This blog post contains a summary on how you can write your own Java classes to process OpenStreetMap (OSM) pbf files. PBF is a compression format, which is nowadays more or less the standard utilized for reading and writing OSM data quickly. In the OSM world, many tools and programs implemented this file format (you can find additional information here). However, I think the following samples for reading and writing such compressed OSM data can be very helpful. In particular, if someone has to create some sort of test data or has to read some specific mapped objects of interest for her/his own project. The well-known Java Osmosis tool (command line application for processing OSM data), provides several libraries that are the basis for this brief tutorial.

Step 1: Maven is the key – If your Java project is already managed by Maven, you can just add the following lines to your pom.xml. It downloads and adds the required jar-files that are needed to process compressed OSM data to your project.

A few months ago, Frederik Ramm posted an idea on the German OpenStreetMap mailing list about a new (stochastic) approach to OSM data quality assurance. You can find his original German post here. His idea was to create a way to allow users to “like” or “dislike” a specific region on the OSM map, a function that other popular websites such as YouTube or Facebook implemented to allow users to provide feedback to videos or status updates. For OSM this particular function could give some indicators or trends about the OSM map data.

I really liked his idea and in collaboration with Frederik I created an Open Source OpenLayers plugin. For all new readers: OpenLayers is an Open Source library which can implement a dynamic (OSM) map into more or less any webpage. One of our goals was to make the integration of the ILikeOSM plugin as easy as adding a tile server to your OpenLayers map.

First of all, I really like the following blog post and the idea behind it: “Yes! It is possible to cross Dublin without passing a pub”

It shows the power of crowd sourced geodata (OpenStreetMap) and the skills of some individuals. In the following steps I am going to show you a different way to get to the same result.

The website OpenRouteService.org offers the same functionality to calculate a route. You can avoid certain areas by defining them (just simply draw them) on the map. However, your first step would be to “Search for Points of Interest (POI)” (PUBS), for example in Dublin within a distance of 10 km. The following picture shows the result:

After that you can create several polygons around your pubs resulting in a map with several, “red” areas:

And finally you can calculate a route from almost any point in Dublin. The last image show such a route without crossing a red area or Pub:

During my Easter holidays I created a web-fronted for Dennis Luxen’s Open Source Routing Machine (OSRM Project). The OSRM project (http://project-osrm.org/) is in my opinion probably the fastest Open Source software which is using data from the OpenStreetMap project. “In contrast to most routing servers OSRM does not use an A* variant to compute shortest path, but Contraction Hierarchies.” You can read a little bit more about Contraction Hierarchies in Wikipedia.

The website that I created contains in its first version an address-search (geocoding) and of course routeplanning. For the geocoding I integrated the Nominatim search from OpenStreetMap. You can find a How-To on the MapQuest-site. Unfortunately the OSRM routing service covers only most parts of Europe for now. The current version of my web-fronted can be found here: http://map.project-osrm.org

Since September 5 th Osmosis supports the new OSM binary fileformat. It sounds interesting, but where are the pros of this format?

I played a little bit with the OSM file of entire Europe. The europe (*.osm) file has an uncompressed format size of about 72.9 GB (compressed it is about 5.2 GB). The new OSM binary (*.pbf) file on the other hand has a size of 3.7 GB (compress=deflate) or 7.6 GB (compress=none).

With the help of Osmosis, it’s quite simple to update an OSM file daily via the “diff” files. You can find a good “how to” in the OSM wiki (here).

For the past 5 days, I collected the processing times that Osmosis (version 0.37) takes to update the europe *.osm file. The osmosis job contains the download of the change (*.osc) file and the cutting (bounding-polygon parameter) of Europe. Altogether the job runs at average in 56min. With the OSM *.pbf file the same task is completed in 14min. I think this is a big difference. So if you need an OSM file on your system, give the new binary OSM files a try! Really nice work Scott 🙂

Nearly three months ago I saw a tweet by mapperz (here). The tweet introduced http://www.openheatmap.com (OHM) : “Turn your spreadsheet into a map” . A very interesting tool. Unfortunately I completely forgot about it in the past weeks until last night. I was looking for an easy method to present some data on a map.

Using OHM is really simple. Upload your CSV file, which suits a certain format, and your data is more or less presented on an OpenStreetMap basemap 🙂

In my case, I used the TMC data of Germany for one week (since 2010-09-12) to present it on a map. For each intersection I counted the number of traffic messages for that specific week. The red areas in the map represent those intersections with a high concentration of messages. My result-OHM-map can be found here: http://www.openheatmap.com/view.html?map=OverestimatedOdessasShevat

The visualization of the CSV file looks pretty cool, doesn’t it? Especially the Berlin area shows a very nice representation of TMC messages.

Im letzten Artikel mit ähnlicher Überschrift hatte ich ein kleines HowTo gezeigt wie man mit Hilfe von OpenStreetMap (OSM) eine Online-Karte mit den jeweiligen Erreichbarkeitspolygonen von Feuerwehrhäusern oder auch für andere Einsatzzentralen erstellen kann (siehe hier!). Das Polygon wurde dabei über eine Zeitangabe berechnet.

Neben dieser Variante könnte man das Polygon aber auch über eine Maximal zu erreichende Distanz bestimmen. Stephan (SB79) hat in seinem Kommentar zum letzten Post danach gefragt. Da der Web Service diese Funktionalität unterstützt habe ich sie auch in das Tool vom letzten Mal eingebaut.

Möchtet ihr das Erreichbarkeitspolygon für eine vorgegebene Zeit um eine Position (lon lat) haben, ändert sich an der Anfrage nichts: http://openls.geog.uni-heidelberg.de/connector/get/analysepolygon/4/7.967585 51.177403

Polygon nach Zeit

Polygon nach Distanz (*NEW*)

Wollt ihr aber zusätzlich für diese Position (lon lat) auch ein Polygon haben was die “Maximale” Distanz in die verschiedenen Richtungen zeigt, könnt ihr nun folgendes nutzen: http://openls.geog.uni-heidelberg.de/connector/get/analysepolygon/4000m/7.967585 51.177403

Welches Gebiet kann von einer Einsatzzentrale der Polizei, der Feuerwehr oder von Ersthelfern in einer vorgegebenen Zeit abgedeckt werden? Andreas versucht gerade dies für die Feuerwehr seiner Gemeinde zu visualisieren. Das erste Ergebnis: Die Standorte der Löschgruppen und die Gebiete die erreicht werden können als Kreise auf einer OpenStreetMap Karte. Das folgende Bild zeigt das Resultat (Rote Marker = Feuerwehrhäuser, Gelbe Kreise = Erreichbarkeitsgebiet und Schwarze Linie = Grenze der Gemeinde):

Bei weiteren Recherchen ist er auf die OSM Erreichbarkeitsanalyse gestoßen (Accessibility Analysis Service). Dieser Dienst ermittelt ein Polygon, dass ein Gebiet repräsentiert was in einer vorgegebenen Zeit erreicht werden kann. Vor drei Tagen hat mich Andreas angeschrieben und gefragt ob ich ihn bei der Verwendung des Dienstes und der Realisierung etwas unterstützen könnte. Im folgenden Bild ist das Ergebnis mit den Polygonen (orange) der Erreichbarkeitsanalyse zu sehen:

Insgesamt finde ich ist dies wieder ein gutes Beispiel was mit OSM und den vorhandenen Diensten wie Mapnik und entsprechenden Programmen wie Openlayers möglich ist. Man muss sich lediglich etwas reinfuchsen und dann kann man so schöne Sachen machen wie Andreas … 🙂