SunCobalt's Diary

Recent diary entries

OSM the Legal Monster

Posted by SunCobalt on 23 April 2020 in English.

When I start using OSM’s website, I must agree with the Terms of Use with 2873 words, already exceeding Instagram’s Terms of Use which comes with 2622 words.

In OSM’s Terms of Use I am pointed to the Privacy Policy with another 3409 word. Then I should read the Copyright and License website with 607 words. This site explains that OSM’s data is licensed under ODbL with 4148 words and the tiles are made available under CC BY-SA 2.0 with 2221 words. It also explains that OSM has a Trademark Policy with 3256 words. If I have not given up and decide to contribute to OSM, I must agree on the Contributor Terms with 883 words.

With a subtotal of appr 17.3k words, we have exceeded the US constitution with 4543 words, the US Bill of Rights with 7591, Macbeth from Shakespeare with 17121 words and Microsoft’s ToS for its entire suite of products having 15260.

Let’s assume you like experimenting with OSM and set up a website with a map and some OSM based services around…just for demonstration. You are expected to read the Tile Usage Policy with 651 words, the Nominatim Usage Policy with 601 and the API Usage policy with 488. If you are starting, you probably don’t need to care about the Banner Policy with only 284 words and the New Tile Layer Policy with 399.

After you are through all of that but before you start editing, you should making yourself familiar with the non-legal guidelines such as for Mechanical Edits and Import (maybe more), and if you want to join discusssions with the community there exist a draft for the Community Code of Conduct and you should consider reading the Etiquette and Suggested code of conduct for OpenStreetMap Mailing lists

Is it planned to create a “Legal Planet File” will all the text and made a minutely replication possible as with so many documents chances are high that one changes?

Will the DWG block us all one day? - Part II

Posted by SunCobalt on 26 May 2018 in English. Last updated on 30 May 2018.

As recently suggested in my previous post “Will the DWG block us all one day?” I took a deeper look into it. I have scraped all 1934 user blocks available last friday together with some user information.

As already indicated, the DWG is blocking more and more user (< no judgement) …. probably along with the increasing interest in OSM and the influx of trolls and paid editors.

In May 2015 an user registered more than 100 accounts with names of public transport stations in Berlin and was blocked. In October 2017 around 60 accounts related with an education session called COMS2200A were blocked. During April 2018 29 accounts from GlobalLogic India were causing troubles and got blocked after a complaint in the user blogs.


If the trend continues, 2018 will be another record year of user blocks.

MedianBlocks On the other hand, the median block duration is at a very low level. (in case someone does not like annualisation, here is a YTD May chart.

If you look who is blocked, you can see that the vast majority are newbies. A mapper is considered as new if the account age at block date is less than 6 months. (If one is blocked more often, he could fall in both categories) However, experienced mapper blocks are also on the rise slowly on average. BlocksByType

The average block duration (chart in months) seems to be unrelated to the mapper type. The spike in 2014 is mainly caused by the 100 years block of user Sorein. In 2016 emacsen blocked some new users for 10 years which resulted in the other spike. Example


[irony] Just in case there are some troubles with the DWG (I am looking into it for a friend), you may want to know whom to avoid. [/irony]


The chart shows the average block length in months. The bubble size represents the number of blocks made. DWG stand for the OSMF Data Working Group account. They blocked 6 accounts for 9 years, all belonging to one criminal case. The other outlier is emacsen, which -as mentioned earlier- blocked someone forever. So let’s leave this aside.


[irony] In case you are in trouble, you should avoid Peda, SomeoneElse and woodpeck if you are a new mapper. Try pnorman instead. If you are already a while around, SomeoneElse seems to be a better choice than pnorman and woodpeck. [/irony]


I have noticed a trend that user blocks are more and more “requested” for things that were accepted in past (i.e. not responding messages/empty changeset comments etc).

Although OSM claims to have 4,607,162 users [1] only 16,431 were editing during the past week [1]. On the other hand, I have counted roughly 1,800 user blocks [2]. I know that one user can receive multiple blocks. However, the proportion seems odd. Looking at the chart, I have two questions in mind. Altough the DWG creates regular reports, there is nothing about this in it.

  • Is it an erroneous assumption that the barriers for blocking users were lowered over the time? And is there a list like ignoring changeset comments is still above the level for being blocked but ignoring user messages isn’t?

  • What is the reason for publishing the stigma of a received user block on his/her profile page as well as in the “list of shame” [2] over a period of more than 8 years now? Does the limitation of purpose by the GDPR for data stored apply?

Thanks a lot


[2] manually counted, adjusted by ~130 for the Berlin train station user.

Just this weekend my ordered mini computer arrived after waiting two months. Basically, it is a single core ARMv7 processor with 800Mhz, 1GB RAM, 1000baseT Ethernet and a MicroSD instead of a harddisk (plus some other features). Its size is 55x55x42mm and weights 91g. The power consumtion is around 3W and less than 1W at standby. I am runing it unter Ubuntu.

Alt text

First I was struggeling a while with the software because there are not so many packages avaible for ARM as I am used to have with a straight forward x86 computer. I wanted to give Mapnik a try but without success. I ended with PostgreSQL 8.4 + PostGIS and an old version of Mapserver 5.6.x - thanks to precompiled bins at launchpad. Luckily I had some older rendering rules for this mapserver version here (thanks to the mapserver-utils project). So some hours later I made it….loaded a 30MB *.osm.bz2 file (300MB database size) into PostgreSQL and got it rendered.

Alt text

What I have learnt is that unlike my “normal” rendering computer, where IO is the bottleneck, here it is the slow single core CPU. Personally I am a bit surprised how good it works. Okay, slow but faster much faster than I have expected….somehow like an internet connection from the old days.

Alt text