Most of you know that OSM will change its license. This means that all data of the OSM project must be relicensed and therefore the contributors have to accept the new contributor terms. Some information about the new ODbL license can be found here.

Since October 9th or rather 10th there is a list of OSM member accounts available that have agreed to the new license. Here you can find Richard’s announcement in the OSMF blog and Matt’s announcement on legal-talk@openstreetmap.org.

Based on my “How did you contribute to OpenStreetMap?” database and the just mentioned “agreed users” list, I created some stats. Sadly they are (still) not up to date, but in my opinion interesting enough to publish them here anyway. In the first attempt I used the last modifier of an OSM object (node/way/relation) as the owner of the object. On the second analysis I use the creator (version=”1″) as the owner of the object.

In my OSM-User-Database of 10/13/2010 a total of 104354* members are the “owners” of the following OSM objects (* Notice: Not every member of the OSM project has contributed!):

• Number of nodes : 801562971
• Number of ways : 66719256
• Number of relations: 765276

You can find the current status of the OSM database statistics here.

As of Oct. 10 th, 2010 (00:00), 2831 Users have accepted the new license. 18054 new OSM members (uid >= 286582) have accept the new contributor terms automatically. I created the following numbers of OSM objects, which will be available for relicensing (at the above mentioned date of my data). If you assume that the last modifier is the owner of the object: (the numbers in brackets represent the percentage of the total objects!)

• Number of nodes : 448027992 (55,8943%)
• Number of ways : 31734455 (47,5642%)
• Number of relations: 237699 (31,0606%)

As I mentioned above, I did the same analysis with a second dataset in which the creator is also the owner of the OSM object (my table is based on the full-history-dump of August 1, 2010). A total of 98415 members created:

• Number of nodes : 796020493
• Number of ways : 63879479
• Number of relations: (numbers available soon)

And the following numbers of OSM objects will be available for relicensing:

• Number of nodes : 431778708 (54,2422%)
• Number of ways : 29885534 (46,7842%)
• Number of relations: (numbers available soon)

Remember, these statistics contain the TIGER import! If you extract this import, surely the percentage of nodes and ways are less, about 14% or even more? Maybe there a several data imports which have to be considered in the numbers? Has anyone else analyzed this before? However, I try to repeat these stats in the near future…

thx @ “the fabulous” dennis

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 🙂

Some system information: (i7-920) Quadcore with 4x 2667MHz, 1500GB HDD and 12GB RAM. thx @ dennis

As mentioned in my last post, I am trying to conduct some statistics for the “Routing View EU” each month that show the areas where the amounts of errors have changed.

Over all (according to the Geofabrik extract) the following amounts of errors appear for the area of Europe at the moment:

• Unconnected Roads: ca. 108000
• Duplicate Ways (number of duplicate segments): ca. 182000

This means that compared to last month about 3000 unconnected streets and 31000 duplicate way segment errors have been removed in Europe. The following image shows the amount of errors divided by country:

If Italy keeps up the good work (-11000 errors) it will catch up with Germany in one or two months. But also Austria, France and Norway were able to correct a lot of errors. For some reason the United Kingdom does not show much of a difference and still has a high amount of errors!?

The following diagram shows the total amount of errors (1m, 2m, 5m unconnected & duplicate way segments) by country compared for each month:

As I did during the past couple of months, again the comparison of federal states of Germany that included the error type “Unconnected 1m” including this month, shown below:

The federal states of Germany are split into three thirds at the moment. In one third of the states errors are being corrected, the second third shows no changes and the last third even shows an increase of errors!?

thx @ dennis 😉

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.

Generally speaking, Pete’s Projekt http://www.openheatmap.com is working very well. A few adjustments still need to be made though. It would be nice to include a zoom function that works with the mouse wheel. Probably this was one of the first problems you encountered too?! But still: Keep up the good work!

thx @ georg for supporting the TMC Database dump
and again thx @ dennis !

Some time ago I saw a diagram on the OpenStreetMaps statistics pages which showed the contribution of OSM Data by contributor in percent (here). This diagram was created last year (2009).

I tried to repeat this interesting analysis with the latest OSM data to see if there have been any significant changes. The following diagrams show the results of this analysis using the mid-august OSM data. The last modifier of an object is being considered as owner. (I think it has been handled the same way in the diagram of 2009?)

Contribution of Nodes

Contribution of Ways

Contribution of Relations

The results are more or less identical to the ones from last year. 98% of the OSM data are distributed on almost 10000 contributors in 2009 and 12000 contributors in 2010.

Based on my “How did you contribute to OpenStreetMap ?” and the used full planet dump (08/01/2010) I tried to create the same diagrams but based on the contributor who created the objects (version=”1”). The results are as followed:

Contribution of Nodes

Contribution of Ways

Contribution of Relations

I personally expected that the diagrams would change based on the questions “Who created the object?” and “Who worked on the object the last?”, but one needs to take a very close look to determine the differences within the stats. This means that more or less just about 12000 members have been working on the DB and contributed most of the data … what do you think?

thx @ dennis

The OSMI Routing View for entire Europe is available for two weeks now. I try to create the stats for the view once a month as I did before. For all readers that are not familiar with the Routing View, you can find some information about it here:

• OSM Inspector (OSMI) – http://wiki.openstreetmap.org/wiki/Osmi
• OSMI Routing View – http://wiki.osm.org/…/Views/Routing
• Direct link – http://tools.geofabrik.de/osmi/?view=routing

Over all (according to the Geofabrik extract) the following amount of errors appear for the area of Europe at the moment:

• Unconnected Roads: ca. 111000
• Duplicate Ways (number of duplicate segments): ca. 213000

The following image shows the amount of errors divided by country. :

Here is another diagram of the “Top” six countries (with more than 10k errors):

It’s important to mention though that the German Routing View is available for half a year now! The total number of errors was over 50000 in Germany at the beginning too.

So I’m excited to see which country will be able to correct a noticeable number of errors first! It will be interesting to see the new numbers next month … Germany has done a good start 🙂

In the past I always created a federal state comparison for Germany that included the error type “Unconnected 1m”, I think we should keep that up?!

In North Rhine-Westphalia and Hessen bigger changes have been made 🙂
Only Bavaria does not show a lot of improvement 🙁

Since last week there is a website available, which is able to display how you contributed to the OpenStreetMap (OSM) project: http://hdyc.neis-one.org

Today, I made some small updates. The picture below shows the changes in the website. First (1) I imported the new planet data (Planet Dump 09/15/2010) that shows you on which OSM objects you are the most recent modifier. *NEW* is that the timestamp of your first contribution to OSM is displayed (see (2)!), further a link to your first OSM Node is attached (3).

How did you contribute to OpenStreetMap ?

So: “How did you contribute to OpenStreetMap?” Use your UserLink and share it with other OSM members (3) … 🙂

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

Die Anfragearten unterscheiden sich leicht. Wenn ihr nur eine Zahl zwischen 2 und 15 angebt, wird das Polygon für die Zeit ermittelt. Enthält die URL stattdessen neben der Zahl auch ein “m” wird das Polygon für die übergebene Distanz in Meter berechnet.

Ich hoffe das hilft … 🙂

Last week I was able to present a variety of statistics that showed the amount of OpenStreetMap (OSM) members of the database compared with the numbers of  the actual amount of registered members.  However, I was just able to consider the most recent dataset (Planet Dump 08/19/2009) and could not take the history of the different objects into account. The results of this first analysis showed that last changes in the OSM database have been made by a total of 98.000 members.

In one of the comments to this post, Apmon mentioned that he had conducted a pretty similar analysis in the past but he had used the changeset file. In his case the results showed about 130.000 members that had contributed to OSM.

For a couple of months now there is a, for now still experimental, full planet dump file available, which also considers the history of the OSM objects. I repeated my analysis from last week with this dump file and counted all the members that ever created a node, a way and/or relation or modified any of them. The results showed about 112.000 OSM members.

I was still surprised by the differences between the results of my analysis and the one conducted by Apmon. So I took a closer look at the changeset-file. Using the most recent changeset-file (08/25/2010) I received a pretty similar amount of almost 132.000 members that assumedly made changes in OSM. However, the results show that there is a noticeable difference between the changeset-file and the planet-file. But where does this difference come from? Could there be changesets that have been recorded although nothing has ever been changed in the OSM database? Apparently the answer is “yes”! The number of members in the changeset file that caused a changeset but never included any actual changes is around 16.000. I asked Frederik how this could be possible. He and Matt explained that as soon as a member signs in with Potlach a changeset is created automatically for this user. This means that 16.000 members signed in with Potlach but never made any changes in the database? Very interesting number, isn’t it? Did the “new” members only take a look at the editor or were they overstrained?

By Damien Cox

There was another comment to the last post by Harry, who suggested, to send an email to all OSM members, for example afterfinishing Potlach 2. This way the “non-active” members might get active and interested in the project again. I think this is a great idea! Although there are a few things that need to be considered before doing this, as Harry mentions in his comment …

… and again: thx @ dennis !

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 … 🙂

Hier noch ein kleines HowTo

1. Informationen wie ihr die OSM Map in euer Webseite integriert findet ihr hier: http://wiki.openstreetmap.org/wiki/OpenLayers – Bei Examples sind jede Menge Beispiele gelistet.
2. Um ein Erreichbarkeitspolygon berechnen zu lassen und als KML File speichern zu können habe ich folgende Seite gebaut: http://openls.geog.uni-heidelberg.de/connector/get/analysepolygon/8/7.967585 51.177403 Sie kann nach dem REST-Prinzip verwendet werden. Ihr müsst lediglich die Minuten (hier 8 Minuten) und die Koordinate des Standpunkte (lon=7.967585 lat=51.177403) in die URL eintragen. Wichtig: Erst Longitude (Längengrad) und dann Latitude (Breitengrad) des Standpunktes! Danach erhält man ein KML File das gespeichert werden muss! ACHTUNG: verwendet dieses Tool bitte NUR zur Erstellung der KML Files, verwendet diese URL bitte NICHT direkt in eurer Webseite. Weiterhin habe ich ein Limit eingebaut, das lediglich ein Polygon für die Erreichbarkeit von 2 bis 15 Minuten erstellt werden kann.
3. Das KML könnt ihr über folgende zwei Zeilen auf eurer Map anzeigen lassen:
   var myKML = new OpenLayers.Layer.GML(“myKML “, ” myKML.xml”, { format: OpenLayers.Format.KML, formatOptions: { extractStyles: false, extractAttributes: false }, projection: map.displayProjection });
   map.addLayer(myKML);
4. Viel Spass … !