Last year we wrote a journal paper in which we analyzed the OpenStreetMap (OSM) dataset of the United States which was published on May 28th, 2013 in the Transactions in GIS Journal. You can download a free pre-print version here. This paper has been published just on time to add to the discussion at the upcoming State of the Map United States conference which will take place in San Francisco and includes some presentations about data imports to OSM. Unfortunately, Dennis and I cannot attend the conference this year, so we decided to write a blog post with some additional and up-to-date numbers.

In January there was an announcement on the OSM mailing list that in the past few months many connectivity errors in the United States OSM dataset had been fixed. Probably a lot of these fixes can be attributed to Martijn’s Maproulette website or to Geofabrik’s OSM Inspector (OSMI) Routing View. However, a short discussion started on the mailing list about the total number of errors that are left and how long it would take to fix all those errors. Thus, we downloaded four OSM planet files dated Jan 4th 2012, June 13th 2012, Jan 2nd 2013 and Jun 2nd 2013 to get some new results. After cutting the United States dataset from the planet files, we used the same algorithm as utilized in OSMI’s Routing View, to receive some stats about the street network of the US datasets.

First of all the, the following image shows the number of errors for each dataset that we included in the analysis. The errors that were detected are separated into unconnected and duplicate ways. You can find some additional information about both error types here.

As you can see, the number of unconnected OSM ways has been rapidly reduced in the past 17 months from around 141,000 to 19,000. The number of “duplicate way” errors has been reduced from 17,500 to 11,500. You can find the exact numbers in the following table and an updated error layer on the mentioned OSMI website. In certain cases the duplicate way error created several errors for one and the same way. For these particular cases the number of unique OSM way IDs were counted.

Date – Unconnected Ways – Duplicate Ways

• Jan 4th, 2012 – 141,578 – unique 17,563 (overall errors: 535,923)
• June 13th, 2012 – 145,468 – unique 17,977 (overall errors: 518,536)
• Jan 2nd, 2013 – 15,911 – unique 12,287 (overall errors: 257,388)
• Jun 2nd, 2013 – 19,073 – unique 11,582 (overall errors: 220,451)

Overall the length of the US street network did not really change a lot. At the beginning of 2012 it was around 11.07 million km while in 2013 it is 11.1 million km, which means an increase of around 30,000 km. The following image shows the distribution of the US street network divided by different OSM road classes.

The length of the residential roads is still decreasing (-496,000 km), similar to what we saw during the analysis for our paper, while the length of the other road types (+276,000 km) and secondary/tertiary roads (+205,000 km) is increasing. This is the result of a massive retagging process of the imported TIGER/Line dataset in OSM. Dennis mentioned this already in his SotM US 2012 presentation. Motorways also experienced an increase of around +44,000 km in 2012. You will find some additional, quite interesting statistics, charts and of course maps in the aforementioned journal publication. In particular a few more thoughts and facts about the effect and impact of data imports on OSM can be found in our research study about the United States OSM dataset.

Really great news for all our non-European OpenStreetMap.org Mappers: Since last month, the OSM Routing View is available for the whole world. You can read more in Frederik’s blog post. Yesterday he sent me the latest results of the view and I did some analysis with it. To all new readers: you can find more information about the OSM Inspector (OSMI) here. The Routing View within the OSMI “shows problems in the data, related to routing and navigation” (direct link).

However, here are the new *worldwide* stats for November 2011: we have a total of about 1,3 Mio errors. We can divide them into the following groups:

• Unconnected 1 meter: 248000
• Unconnected 2 meter: 62000
• Unconnected 5 meter: 170000
• Duplicate (number of duplicate segments): 833000

The following diagram shows the amount of errors per continent:

In the following charts you can see the amount of errors separated by country and the amount of errors in detail per country for “Europe”:

*NEW*: All other non-European countries with more then 5000 errors are listed in the following chart:

The “big three” countries with the highest amount of errors are in the last chart:

As you can see it in the charts, especially the United States need a lot of work. Furthermore it seems that in Ethiopia something went wrong. Was there any data-import or something similar? Frederik does not have a sponsor for running this routing view world-wide on a daily basis right now, so please contact him if you would support us! The last Routing View blog post is online here.

thx @ *Fab*

Maybe some of you remember that I conducted a comparison analysis between three OpenStreetMap (OSM) routing engine APIs (CloudMade, MapQuest Open and OSRM) and G**gle Maps API last week. You can find the results in my blog post here. As I mentioned in the article, I wanted to try to do a second analysis with more routing engines.

Thus, I added Bing Maps and two OSM engines (YourNavigation/YOURS and Routino/Roadeeno) to the comparison. All services have a continental coverage with the exception of OSRM. The following table shows an overview of (1) the request-response time of the service, (2) the calculated distance for the test-route and (3) the file size of the service response:

As you can see in the following diagram does the OSM routing engine (OSRM) give the fastest results. A little bit strange is that the Routino/Roadeeno service returns no valid route responses for requests which are longer than 600 km.

The same diagram in a more detailed view:

The routing engines have different ping times (round-trip time). Almost all services have a round-trip time off about 25 ms. You can see the times for each engine in the following diagram:

If you take those ping times into account and use a logarithmic transformation, the result look as shown below:

The above diagram shows in a quite impressive way the results of this comparison that allow the following conclusions: OSRM (OSM) shows the fastest results followed by G**gle Maps (Tele Atlas). Bing (Navteq), MapQuest (OSM) and CloudMade (OSM) are nearly equal in most cases. YOURS (OSM) and Routino (OSM) seem not to be the right choices at least for long route calculations (>600km). Maybe a second comparison with several routes between 10 and 500 km could be an enhancement?

thx @ maɪˈæmɪ Dennis 🙂

In the past blog post I wrote about the newest changes and encoding techniques that have been implemented in the Open Source Routing Project (OSRM). So I think it is time do a little comparison analysis about the request/response time of several routing APIs. The main question I wanted to answer was: “Is an OpenStreetMap direction service faster than G**gle?” I tested the following direction APIs for cars (fastest): MapQuest, CloudMade, G**gle and finally OSRM. For the analyses I wrote a small Java tool, which measured the time to get a result of a routing-service. I did all tests at home with a “regular” 12kbit/s internet connection. I tested several distance levels and the results can be seen in the following table. It shows the average times of five requests for each route with a delay of 3 seconds between each request/response. Overall I did this analysis three times.

The results are quite impressive. OSRM calculates the fastest route for all five test routes! Unfortunately we do not have any information about the server infrastructure at G**gle, MapQuest or CloudMade but the OSRM engine is running on a virtual server with limited hardware resources. It seems that the CloudMade directions service does not like Paris very much, as can be seen in the following image 😉

I will try to do a second comparison with Bing Maps, YOURS and Routino. So stay tuned …

— Update —

>> The second blog post is here: Comparison of (OSM) routing-engines – Reloaded <<

thx @ maɪˈæmɪ Dennis 🙂

One of the many bottle necks of today’s web services are network latency and bandwidth. While I was working on a research paper, I recognized that G**gle encodes some information when you calculate a route on G**gle Maps. This process reduces, besides the gzip compression, the response from the server. This means that this is a speed improvement for the server client communication besides the zoom-level-generalization. You can read more about the “Encoded Polyline Algorithm Format” and how it works here.

We integrated this nice feature into the code of the Open Source Routing Machine (OSRM) project. The following table shows a few results for some sample routes comparing the old and the new file sizes (@ zoomlevel 18):

And if you are not a numbers person, let us put this in perspective: The fast routes just got faster! And that’s not all. As a second new feature the web frontend of the OSRM has shortlinks for the calculated route now. You can find the link of your route at the route summary. Try it out here: http://map.project-osrm.org/

thx @ maɪˈæmɪ Dennis 🙂

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

Anyway, perhaps some of you would say: “A website with OSM routing? This is nothing new and we actually did have something like that before …” I agree, BUT I think none of them is as fast and can handle as many requests, try it out! Through its really good route calculation performance the route can also be changed or adjusted by dragging the start- and destination point (I think you know this from other websites). The following video shows the great functionality:

WebGUI for Project-OSRM from Pascal Neis

Further does the new website automatically generalize the desired route on the server side for smaller map scales. This reduces the traffic between server and client and less data needs to be visualized by the client which saves system resources. Additionally I created the following feature: If a calculated route contains a segment that has no name, it is going to be displayed in a different color. I think this is a great feature to map missed road names! The next picture shows such a route. You can find the complete sources of the website in the OSRM Sourceforge project folder.

There is a lot of discussion on OpenStreetMap.org about a Routing-Integration. In my opinion there should be two routing options available on the OSM start page. One option that provides a very fast routing such as OSRM and another option that is easy to adjust and configure and is able to work with different OSM tags. A combination of both will probably not be available soon. Bigger companies such as “G****E” offer high performance routing applications to their users. Thus it should also be a desirable goal for the new OSM software to get to the same performance level that the users are familiar with from other websites. I don’t think that an integration of ”Non-Open-Source Routing Software” such as provided by CloudMade or Mapquest is a good idea. It still should be an Open Source App after all. But this limits the selection to OSRM, YOURS, Routino and Roadeeno. For now OpenRouteService is not completely Open Source.

So *if* we add routing to the OSM main website I would vote for a fast-route-planning software e.g. by the OSRM project. Hence we must only search for a preferably configurable solution, what would be your suggestion?

thx @ Dennis L.: Continue with your great work!
thx @ Frederik (Geofabrik) for supporting the OSRM Project with a VM for hosting
thx @ *Fab* for the video
and finally: thx @ maɪˈæmɪ Dennis 🙂

First of all, sorry that I did not create a new stat regarding the Routing View past month. To all the new readers: Usually I create an analysis about the Routing View of the OpenStreetMap Inspector for each month for Europe. You can find more information about the OSM Inspector (OSMI) here. The Routing View within the OSMI “shows problems in the data related to routing and navigation”. You can read more about it here … A direkt link to the OSMI Routing View is here!

However, here are the new stats for May, 2011: we have a total of about 124000 “Unconnected Roads” and about 108000 “Duplicate Ways” (number of duplicate segments). Overall this means that we have about 17000 *new* „Unconnected Roads” errors and only ca. 1300 “Duplicate Ways” have been fixed in Europe. For the past three months we have an increment of about 2850000 new OSM way segments for routing. (May 7th: 34500000, February 20th: 31700000, January 20th: 30600000)

In the following images you can see the amount of errors divided by country and the amount of errors in detail per country for “Europe”:

For this month only a few countries were able to reduce their errors. France (-2200) and Poland (-4800) are ahead of everyone else, so Poland this is your month 🙂 Here you can find the February stat of the OSMI Routing View. Hopefully this is going to be better in the next month :S …

thx @ maɪˈæmɪ Dennis 🙂

This month I tried something new. But first we will start with the usual monthly stats of the OSM Inspector Routing for Europe, this time for the middle of February 2011. Overall the following amount of errors appears for “Europe”: Unconnected Roads: ca. 107000 and Duplicate Ways (number of duplicate segments): ca. 109000 (in the OSM Wiki you can find more information about the error-types). This means that altogether there are 2600 unconnected streets and 16900 duplicate way segment errors have been fixed. In total we have an increment of 1111000 new OSM way segments for routing during the past 4 weeks in Europe (01/20/2011: 30600000, 02/20/2011: 31710000).

The following image shows the amount of errors divided by country for today’s Europe OpenStreetMap dataset:

In the past month several other countries were able to reduce the amount of errors, such as in: France (-1600), Italy (-1600), Poland (-1900), Sweden (-2300) and United Kingdom (-8000!!!). So congratulation to the UK, this is your month 🙂

Now let’s take a look at the new diagram: The following image shows the amount of errors per 100 km OpenStreetMap streetnetwork data for each country.

Do you have any other ideas for additional diagrams? I think dividing the amount of errors for each country by the number of OSM ways or segments could be an interesting approach, what do you think? The last image shows the amount of errors divided by country:

thx @ Dennis

Overall the following amount of errors appears for “Europe” at the middle of January 2011:

• Unconnected Roads: ca. 109600
• Duplicate Ways (number of duplicate segments): ca. 125900
• (read more about the error-types here)

This means that altogether there are 3000 unconnected streets and 13400 duplicate way segment errors have been fixed (last month we had 112600 unconnected roads and 139000 duplicate ways errors). In total we have an increment of 1139000 (+3.8%) new OSM way segments for routing during the past 4 weeks in Europe!

• 12/23/2010: 29400000
• 01/20/2011: 30600000

The following image shows the amount of errors divided by country for today’s Europe OpenStreetMap dataset:

In the past month several other countries were able to reduce the amount of errors, such as in: France (-2900), Portugal (-2900) and Romania (-2200). So I think the award for this month goes to Portugal 🙂 (Is the reduction a result of this action? However, nice work!). But further countries such as Albania, Belgium, Bosnia and Herzegovina, Bulgaria, Germany, Greece, Slovakia and Sweden were able to reduce more than 1000 errors each. Only Spain (+1200) and the United Kingdom (+2000) have a gained more errors!

The following diagram shows the total amount of errors for 1m, 2m, 5m unconnected & duplicate way segments:

As usual for Germany, the comparison of federal states (includes the error type “Unconnected 1m”):

Yay, nearly all federal states could reduce their amount of errors!

thx @ Dennis

Short update with new statistics for the “Routing View EU“. Overall the following amount of errors appears for “Europe” at the middle of December 2010:

• Unconnected Roads: ca. 112600
• Duplicate Ways (number of duplicate segments): ca. 139000
• read more about the error-types here

This means that altogether there are 5100 new unconnected streets and 20000 duplicate way segment errors have been fixed (last month we had 107500 unconnected roads and 160000 duplicate way errors). In total we have an increment of 1300000 (+4.6%) new OSM way segments for routing in the past 5 weeks in “Europe” (this is nearly twice the number in comparison to one month ago)!

The following image shows the amount of errors divided by country for today’s Europe dataset:

In the past month several other countries were able to reduce the amount of errors, such as in: Austria (-3200), France (-4400), Italy (-2100), Portugal (-1200), Sweden (-2000), Switzerland (-4828 !!) and the United Kingdom (-3700). So I think the award for this month goes to Switzerland 🙂 . Germany keeps going on with its negative trend: A gain of about 2700 errors! It seems like the German OSM community is primarly tracing from Bing-imagerys, doesn´t it?

In the following diagram the bars for each country shows the total amount of errors for 1m, 2m, 5m unconnected & duplicate way segments:

As usual for Germany, the comparison of federal states (includes the error type “Unconnected 1m”):

(Nearly all federal states have a positive value regarding the amount of errors, except Rheinland-Pfalz, Sachsen, Schleswig-Holstein & Hamburg)

This was my last blog post for this year, so Merry Christmas and a Happy New Year 2011!
Bye for now …