Users' diaries

Recent diary entries

Kulturní a náboženské památky

Posted by MapperDB on 23 October 2016 in Czech (Česky)

Tagging destination lanes in Sardinia

Posted by dan980 on 23 October 2016 in Italian (Italiano)


Today I started adding the tag key:destination to the main primary and secondary roads in Sardinia. I'm using my knowledge of the roads and/or the layout of the network. This is very useful for navigator software: Osmand, Magic Hearth, Skobbler gives you voice directions on where to turn (in 500 meters take the exit to Sassari).

Check the wiki as reference:


Oggi ho iniziato a etichettare la chiave key:destination alle principali strade primarie e secondarie della Sardegna. Mi baso a seconda dei casi in parte sulla conoscenza locale o sulla configurazione della rete stradale. Si tratta di un etichetta molto utile per i navigatori: Osmand, Magic Earth e Skobbler danno indicazioni vocali in merito (fra 500 metri prendi l'uscita in direzione Sassari).


Mysterious Markers Solved?

Posted by alexkemp on 22 October 2016 in English (English)

My latest survey of Porchester Gardens — just another couple of days surveying before it should be completed — has unearthed more of these lead markers and, possibly, has answered what they are. Here are two pictures from today's trip [1] [2]:

Kent Road 1 Kent Road 2

The second picture is, I think, the key to unlock this: they are more-ancient versions of the traditional grave-stone wall-plates used to indicate the presence of Fire Hydrants or Sluice Valves (sewage safety feature). So, the prize goes to EdLoach (commentator in Mysterious Marker #2).

Do we have any agreed method of mapping these markers?

Location: Porchester Gardens, Arnold and Carlton, Gedling, Nottinghamshire, East Midlands, England, United Kingdom

Missing street names in Sardinia

Posted by dan980 on 22 October 2016 in English (English)

I'm currently updating Sardinia street names, using open data (IODL) from Regione Sardegna.

The best data source is the Geo Topographic Database ( . It covers 125 towns out of 377. The data is pretty accurate.

As a secondary data source I'm using DBT Elemento stradale ( It covers all the towns, but is older and many street names are missing, including main street names (e.g. they are called "Strada Provinciale 12" instead of "Via Roma").

I'm updating the names of existing OSM highways. For missing roads I'm using Mapbox Satellite first.

suna eastern kenya

Posted by mutenyo joan on 22 October 2016 in Abkhazian (Аҧсуа)

22/oct/2016 a team of youth mappers gothered at hive colab in kampala the city of uganda to do a mapathon to help the kenyan community to fight malaria.

Access restriction data architecture

Posted by BushmanK on 22 October 2016 in English (English)

Currently, we have acceptable (but not ideal) tagging scheme for access restrictions. I'm talking about access=* key and its values. Here, I want to tell something about an application of this scheme in terms of topology, data interpretation, and data architecture.

OSM documentation says that it may be used on nodes, ways, closed ways (use on relations is unspecified, but it's not prohibited). And many people take that literally. Let's review some cases.

access=* is often assigned to a node, representing a barrier. Many mappers have an idea that it is way easier to add this tag to a gate, liftgate or another kind of barrier to indicate that access restriction starts here. In such cases, adding access=* to a highway=* is often omitted. A common argument for omitting it is that usually, navigation software starts the route planning from a point, which is publicly accessible. Then, analyzing the road network, it should avoid crossing those points with access=* restriction, if possible, just like it does with user-defined avoidance marks.

But there is a problem with this method. Having a road, divided into two parts by a node with access=* tag, it is impossible to tell, to which half this restriction is applied. This problem has only heuristical solutions, involving extensive analysis of road network. For example, it will be a nice educated guess to say that restricted portion is often a dead-end comprised of lower rank roads, while unrestricted portion likely has a connection with higher rank roads. But this kind of analysis is a problem with no definite depth, and it still doesn't give you 100% accurate result, which is unacceptable.

That argument about a route always starting from a publicly accessible point, is obviously false. There are enough cases when you have to calculate a route from a private property or limited access property. And the only universal way to deal with that is to disregard restrictions completely if no unrestricted route is possible. This solution is widely used, but it means devaluation of information about restrictions in the OSM database. Another known approach is to always avoid passing through the restricted portions of a road network by counting restriction points, but again, in a case of node-based restriction, it fails (requires a fallback to ignoring all restrictions) if both start and finish points are behind the restriction.

Applying access=* to a road itself eliminates any topological ambiguity since there is no question, to which part of a road restriction is applied. It is also clear if a route starts from or/and ends at a restricted portion. Therefore, no fallback is required.

Another option is to apply restrictions to a boundary, such as a fence or a land parcel, where a restriction is in effect. It helps to avoid tagging every road. However, it requires certain pre-processing to make data actually usable. Information about restrictions should be normalized by applying it to roads within a boundary using a spatial query (just like in the case of simplified address tagging, when addr:city is omitted on buildings, but can be easily propagated from a city boundary). To make it right, two additional operations should be performed: splitting roads at an intersection with a boundary, obtaining all members of a boundary contour. The latter one could be tricky if processing is performed offline.

So, it could be a drawback, but it doesn't create any problems with an indefinite depth.

The purpose of this diary entry is to explain how access restrictions work in case of being applied to every type of geometry and to demonstrate that existing node-based restrictions can not be reliably used.

Осенние встречи

Posted by Сергей Голубев on 21 October 2016 in Russian (Русский)

Оригинал с картами тут: http://xn--80afd3balrxz7a.xn--p1ai/osennie-vstrechi/

Приглашаю всех: 27 октября в Ростов-на-Дону на встречу осмеров, гисовцев, любителей карт и геоданных, а равно всех интересующихся или использующих картографические методы в работе, увлечении или учебе. Программа мероприятия такова: следуем в теплое уютное место, где пьем напитки и рассказываем о себе, своей деятельности и достижениях. Встреча исключительно неформальная и ставит целью знакомство и тематическое общение в ходе пары-тройки часов. Встречаемся в 17:00 у передней части паровоза, что стоит в виде памятника у железнодорожного вокзала:

29 октября в Москву на лекцию, посвященную современной цифровой картографии, где ваш непокорный слуга расскажет о том, как устроены современные картографические сервисы (Google maps, Яндекс-карты, OpenStreetMap и др.), объяснит почему спутниковые снимки искажают действительность, пояснит значение важнейших терминов «геоданные» и «картостиль». Мы рассмотрим как менялись парадигмы картографирования, обсудим практическую значимость геоинформационных систем и научимся правильно понимать значение географических координат. Лекция рассчитана на неподготовленных слушателей, поэтому страшных и непонятных вещей там не будет. Мероприятие состоится в 17:00 в «Кафетериусе 13«, что расположен на третьем этаже ТЦ Авиапарк (универмаг Trend Island).

30 октября в 17:00 в этом же «Кафетериусе 13«, я буду рассказывать о фрактальной геометрии окружающего нас мира. Лекция посвящена вопросам измерения времени и пространства. Слушатели узнают о кризисе математики начала XX-го века, кривых-чудовищах и научных спорах о возможности предсказать будущее. Попробуем подсчитать длину береговой линии, а когда поймем, что это невозможно, познакомимся термином «фрактал». Я расскажу о том, что не все ошибки измерения являются именно ошибками и о том, как наше привычное представление о мире может влиять на массовые вымирания видов в истории Земли.

Вход на все мероприятия свободный, но очень большая просьба, всем кто придет, предварительно написать в комментариях к http://xn--80afd3balrxz7a.xn--p1ai/osennie-vstrechi/ или на мою почту При возникновении вопросов связаться со мной можно в любое время по телефону +7-904-614-68-29.

haiti hurricane matthew

Posted by mutenyo joan on 21 October 2016 in Abkhazian (Аҧсуа)

on 21/ oct/ 2016 i participated with other mappers to map haiti after the hurricane matthew. i learnt that haiti is an island and also contribuited by adding some buildings on the map

Wikipedia and OSM collaboration

Posted by naveenpf on 21 October 2016 in English (English)

This something which we have been talking for years ;). Feels so happy that it is ready now.

Maps can be displayed in Wikipedia from OSM relation. Just done it for NH1

Wikipedia ---> Wikidata ---> OSM

How often OSM updates Wikidata id with Wikipedia tag ?

Cemeteries in Texas MapRoulette Challenge now powered by Texas Imagery Service

Posted by mvexel on 20 October 2016 in English (English)

Important note: The imagery I use as an example below is different in source from the imagery used for the MapRoulette imagery. The example below shows imagery that was commissioned by Texas itself, and is available in the public domain. The imagery in the MapRoulette challenge is licensed from Google by Texas and made available to MapRoulette specifically. So I can't say positively that it's OK to add this imagery to JOSM or iD, and removed specific instructions to do so.

Have you tried the Texas Cemetery challenge in MapRoulette? If you have not heard about it yet, I posted about it on my diary a few weeks ago. The short version: the friendly folks at TxDOT supplied me with a database of their known cemetery locations, we matched them with existing OSM, and if there was no match, we ask you to map it :)

If you tried it, you may have found though that it can be a bit frustrating :( Bing and Mapbox aerial imagery is often just not detailed enough to see if there is a cemetery or not in the location indicated. I discussed this problem with the friendly folks over at TxDOT, who are very excited about getting more data into OSM. They told me about some of the high resolution imagery that is available to the public through TNRIS, the Texas Natural Resources Information System. Here is an example of some of the amazing data they have:


If you compare that with Bing, it means the difference between seeing a vague blur or seeing the presence of a cemetery very clearly! Super exciting stuff. So we set out to create a TMS endpoint that we plugged into MapRoulette. See the difference!


Go give it another try! Thank you and thanks TxDOT!

Updated Contributor Statistics

Posted by SimonPoole on 20 October 2016 in English (English)

As at the begin of every new quarter since a couple of years, I've updated the Contributor Statistics on our wiki.

Naturally the most noticeable thing is the large jump in new users and active users starting in April 2016, which is naturally mainly due to new incoming edits from users. This is, on first principles, naturally not a bad thing, and annoyances due to bad edits aside, exposing more people to OSM is good.

What I have however noted in discussion is that the impact of the growth of the raw number of contributors is massively overestimated. For example the number of edits (not changesets) per month is essentially unchanged:

Which is not a surprise given that a maximum 0.18% of the edits per month in 2016 to date have been made with even though at least 1/4 of the active users used the app in the relevant periods. A preliminary comparison with editors that started off with iD show that over the same period the total number of edits per contributor using is smaller too.

There may be some longer term gains that we can't see yet, at least anecdotally I've seen one user do an initial edit and then switch to iD, but the numbers indicate that right now that is the absolute exception.

[Update] Small clarification: the 0.18% number includes all edits not just new contributors.

FacilMap 2 has been released

Posted by Candid Dauth on 20 October 2016 in English (English)

A new version of FacilMap has been released.

Everything has been rewritten from scratch. FacilMap is now based on Leaflet, AngularJS and Bootstrap.

FacilMap is an online map that aims to bring together many useful functions in a usable and pretty way onto an open-source map based on OpenStreetMap.

  • Different map styles: OpenMapSurfer, Mapnik, OpenCycleMap, Hike & Bike map, Public Transportation map, Hillshading overlay
  • Find places and calculate routes. Routes are fully draggable.
  • Show GPX/KML/OSM/GeoJSON files on the map (use Tools → Import File, type a URL into the search field, or simply drag and drop a file onto the map)
  • Show additional information about places (for example opening hours or a link to the website). Press the map for 1 second somewhere to show information about what is there. (Uses Nominatim.)
  • Zoom to the location of your device and follow it.
  • New: Create custom collaborative maps on Markers, lines, routes and even GPX/KML/OSM/GeoJSON files can be added to these maps by everyone who has the link to the editable version of the map (every map has a read-only and a read-write URL), and changes are displayed live to everyone who is looking at the map at the same time. Advanced features include the definition of custom marker/line types with custom form fields and styles and the automatic generation of a map key.
  • Can be easily run on your server or embedded into your website (see below).

Zahl des Monats: 74.9 Prozent

Posted by drolbr on 20 October 2016 in German (Deutsch)

Vorab das Wichtigste: Die neue Version 0.7.53 ist auf und jetzt aktiv. Die Rambler-Instanz wird in den nächsten Tagen folgen.

Weitere Details dazu werde ich weiter unten geben, ebenso, warum ein Vorfall rund um Pokemon Go mein Weltbild zu Zugriffsregeln erschüttert hat.

Doch zunächst möchte ich die Zahl des Monats präsentieren: 74.9 Prozent. Von 74.9 Prozent aller IPv4 /24-Subnetze, also aller überhaupt möglichen solchen Subnetze weltweit, habe ich mittlerweile Zugriffe in den Logfiles gefunden. Zu diesen Netzen gehören z.B. die von General Motors, Ford, Toyota, Daimler, BMW und Volkswagen. Bei Medienhäusern z.B. New York Times, Guardian und Der Spiegel. Weiterhin: SNCF, Deutsche Bahn, SBB, zahlreiche Universitäten und sogar ESRI. Selbstverständlich auch eine lange Liste von gewöhnlichen Internet-Providern. Zur Erinnerung: die Overpass API liegt eher im Maschinenraum und ist mehr technisch als nutzerfreundlich. Daher dürfte die amortisierte Reichweite der diversen Tile-Server noch weitaus höher liegen. Das passt sehr gut zu der Beobachtung, dass große Teile der öffentlichen Verwaltung in Deutschland damit experimentieren, OpenStreetMap in ihre Arbeitsabläufe zu integrieren.

Fazit: OpenStreetMap ist alles andere als klein. Es ist bereits der De-Facto-Standard für Geodaten. Und wenn es Wachstumsgrenzen für OpenStreetMap gibt, dann ist die Wichtigste davon die Größe der Menschheit.

Das heißt nicht, dass eine Mehrheit der Menschheit bereits OpenStreetMap nutzt. Geodaten kann man nicht essen, sie sind auch kein Medikament. Geodaten sind wichtig, aber nicht der Schwerpunkt der Welt. Die Statistik von oben sagt also: Wer sich für Geodaten interessiert, der kennt höchstwahrscheinlich OpenStreetMap.

Daher ist "irrelevant" ein abwegiges Adjektiv für OpenStreetMap. Blog posts, die beides zusammenzubringen versuchen, sind schlicht falsch. Das bedeutet nicht, sie seien böswillig. Aber es bedeutet, dass sie aus einem sehr ungewöhnlichen Umfeld der letzten 25.1 Prozent des Internets kommen. Daher gibt es keinerlei Veranlassung, irgendwelche obskuren und verworrenen Dokumente namens "CoC" in die Community einzuschmuggeln. Die Leute, die damit geworben werden sollen, wird es höchstwahrscheinlich gar nicht geben. Es wäre sehr ungewöhnlich, wenn potentielle neue Mapper mehr Bürokratie als Voraussetzung fordern.

Aber zurück zur Overpass API. Während des Wochenendes rund um den 1. Oktober hat es eine Lastspitze gegeben. Meistens kommen solche Lastspitzen von Entwicklern, die versuchen, unverhältnismäßige Mengen Last auf die API zu beaufschlagen. In diesem Fall hat sich aber herausgestellt, dass die Last über kommt - angesichts der Zielgruppe technisch versierter Nutzer ist das praktisch auszuschließen.

Es hat einige Tage gedauert, bis die Ergebnisse der Suchmaschinen Hilfe für eine Hypothese geliefert haben. ist in der Pokemon-Go-Gemeinde bekannt geworden. Die Prüfung dieser Hypothese hat zutage gefördert, dass an diesem Wochenende von etwa 30'000 verschiedenen IP-Adressen pro Tag auf die Overpass API zugegriffen worden ist - etwa das Doppelte der normalen Nachfrage. Die empfehlenden Seiten geben jedoch reichlich Attributierung von (und Werbung für) OpenStreetMap - eigentlich ist das genau die Art von Außendarstellung, die wir uns wünschen. Von daher ergäbe es keine Sinn, diese Art Abfragen zu sperren, und es ergäbe erst recht keinen Sinn, zu sperren.

Daher ist eine Erkenntnis des Wochenendes, dass ich mich um mehr Server-Kapazität bemühen sollte. Einen Teil des Kapazitätsgewinns werden wir über Software-Verbesserungen von Mmd und mir erreichen können. Aber vermutlich taugt die Overpass API als Aushängeschild für OpenStreetMap-Geodaten ab irgendwann in 2017 nur mit einem zweiten Server. Gerade Geodaten-ferne Nutzer werden vernüftige Antwortzeiten brauchen.

Version 0.7.53 glänzt vor allem mit weniger Bugs. Ein paar neue Features gibt es aber auch: * [!key] kann als einfachere Notitation für [key!~"."] verwendet werden. * Die user-Anweisung kann mehrere Benutzer auf einmal per Komma-getrennter Liste entgegennehmen

Version 0.7.54 wird hoffentlich mit weniger zeitlichem Abstand und schon zum Jahresende fertig. Einige Features habe ich bereits entwickelt, andere sind im SotM-Vortrag (Video sollte folgen) skizziert. Es lohnt also, dranzubleiben. Und sich in der Zwischenzeit an der frohen Botschaft zu erfreuen, dass OpenStreetMap bereits der De-Facto-Standard für allgemeine Geodaten ist.

The number of the month: 74.9 percent

Posted by drolbr on 20 October 2016 in English (English)

The most important news is that version 0.7.53 is now live on the and server. The Rambler server will follow in the next days.

I will give details on this further below. Also below I will explain how an incident with Pokemon Go shaked my mindset about quota policies.

Before this I will present the number of the month: 74.9 percent. From 74.9 percent of the total IPv4 /24 subnets of the entire world I have observed requests in the logfiles. Amongst some random IP block owners from the logfile: General Motors, Ford, Toyota, Daimler, BMW, Volkswagen. Media Outlets: New York Times, Guardian, Der Spiegel. Further starring: SNCF, Deutsche Bahn, SBB, numerous universities and even ESRI. Of course also long lists of telephone carriers. Remember that Overpass API is a quite deeply buried and highly technical service. It is almost sure that the popularity for the combined tile servers is even higher. This matches very good with the observation that half of the public administration in Germany is figuring out how to get OpenStreetMap in their workflow.

Punchline: OpenStreetMap is by no means small. It is the de-facto standard for general purpose geodata. And if there are limits to the growth of OpenStreetMap in sight, then these are most likley the size of mankind.

This does not mean that the majority of mankind is using OpenStreetMap. Please do not forget that you cannot eat geodata. Or substitute drugs. Geodata is in important field, but not the core of the world or the internet. The statistics from above say that whoever is involved in geodata is almost surely aware of OpenStreetMap.

Hence "irrelevant" is an adjective quite entirely unrelated to OpenStreetMap. Blog posts stating otherwise are simply wrong. This need not be a willful misinformation, but it may be an observation from a very unusal environment somewhere in the last 25.1 percent of the IPv4 space. Hence there is no need to have some obscure and complicated extra documents called "CoC" or so just to please unknown people that might not exist at all. Let aside that there is few to no precedence that extra bureaucracy pleases people.

But back to Overpass API. During the weekend around October 1st I have seen a spike in load. Such a spike is most of the time some developer trying to offload undue amounts of requests on the Overpass API. In this case it turns out that the only client responsible for a load spike is ([] - due to the highly technical nature of the tool this is more than unlikely.

It has taken some days until the search engines have delivered the evidence what was going on: has got credits from the remaining Pokemon Go community. Testing against that hypothesis, I found that people have accessed from 30'000 different IP adresses per each day of the weekend on Overpass API - roughly twice the normal. However, there is plenty of credit for OpenStreetMap. From the logs I can observe that a lot of users come from developing countries. And from my personal environment I know that more than half of Pokemon-Go-players are female. Actually I would call this as exactly what we like to achieve with outreach. Hence, neither blocking these users constituting the spike nor blocking altogether would be an option that makes sense.

So a second result of this weekend is that I should ask rather soon for more server capacity. The improvements by Mmd and me may help. But a second server at some point in 2017 would probably help to attract people. Maybe even people that do not yet have a relation to geodata.

Version 0.7.53 excels rather at having fewer bugs than at having new features. There are nonetheless some improvements: * [!key] can be used as shortcut for [key!~"."] * the user statement accepts multiple users as a comma separated list

Version 0.7.54 is hopefully ready at the end of the year. I have already started to develop some features. Others have been sketched in my SotM talk (video tba). So please stay tuned. And in the meantime, please spread the message that OpenStreetMap is already the standard choice for general purpose geodata.


Posted by 山崎 俊輔 on 20 October 2016 in Japanese (日本語)


  • HOT Tasking Manager を開き、解説とインストラクションを読む。
  • 参加をクリックして地図の建物入力したい部分を選択する。
  • マッピング開始をクリックする。
  • 選択した部分の範囲が広いときは分割をクリックする。
  • エディタをiD editorを選択する。
  • OpenStreetMapが開かれエリアをクリックして建物を囲う。
  • 赤い線をクリックし角を直角にする。
  • 建物としてチェックする。
  • 建物をすべてチェックできたら保存を押す。
  • 完了としてマークをクリックしたら、作業は終了。



  • 作業内容確認をクリックする。
  • エディタをiD editorを選択する。
  • ほかの人がやったところでおかしいところや雑なところがあったら、修正したり削除したりする。
  • 修正・削除が終わったら保存する。
  • 確認完了をクリックしたら、作業は終了。


Posted by akari_drm on 20 October 2016 in Japanese (日本語)


  • マップに表示されている作業が未完了のタスクを選択
  • マッピングを開始をクリック
  • タスク対象地域が大きすぎる場合は分割
  • IDエディタよりマップへ
  • 航空写真上で建物をみつけたら、エリアをクリック
  • 建物の形を入力し、直角に整形


  • マップに表示されている作業が未完了のタスクを選択
  • 作業内容確認をクリック
  • IDエディタよりマップへ
  • すでに入力済みの建物の修正を行う


Posted by akari_drm on 20 October 2016 in Japanese (日本語)

#*クライシスマッピング* ##建物の入力作業 ・マップに表示されている作業が未完了の*タスク*を選択 ・マッピングを開始をクリック ・タスク対象地域が大きすぎる場合は分割 ・*IDエディタ*よりマップへ ・航空写真上で建物をみつけたら、エリアをクリック ・建物の形を入力し、直角に整形

##作業内容確認作業 ・マップに表示されている作業が未完了の*タスク*を選択 ・作業内容確認をクリック ・*IDエディタ*よりマップへ ・すでに入力済みの建物の修正を行う


Posted by Hiroki4869 on 20 October 2016 in Japanese (日本語)




 先週の講義では、ハリケーンによって甚大な被害を受けたハイチの建物のマッピングを行いました。また、一通りマッピングの作業を終えた後に、「そもそもなぜマッピングデータを赤十字が欲しているのか?」というお題について各々の意見を出し合い、 * 物資の運搬や人材の派遣における安全性の確保 * 物資や人材の適切な配分 * 被害の程度の確認 など、その他多くの自分では思いつかなかった意見も得ることができました。



10月20日 授業でやったこと

Posted by hisadayuki on 20 October 2016 in Japanese (日本語)



  1. 建物を探す
  2. エリアのボタンをクリックし、建物の周りを囲む
  3. 囲っ図形がを直角になるように補正
  4. セーブする




前半は前回とは別のハリケーンの被害に遭った地域の建物マッピングをしました。 後半は、他人がマッピングをした地域を見て、変更をする作業をしました。エリアの場所に建物がなかったり、建物とエリアの大きさが違かったりして、面白かったです。

# 10/20(木)OpenStreetMap作業

Posted by akari seki on 20 October 2016 in Japanese (日本語)


<建物の入力>  ・Tasking Managerで依頼された地域の分割を行う。多くの人で効率良く行うためにも   小さく分割して行うと良い。  ・地図上で色の付いていない、誰にも作業を行われていない場所を選択し、参加する。  ・マッピングを開始するときにiD editorを選択する。  ・編集を開始し、航空写真上で建物のある場所を囲み建物と登録する。   <作業内容の確認>  ・一人のみの判断で行うと誤差が生じるため、人が行った建物登録の確認作業を行う。  ・これもiD editorで行う。  ・地図上でオレンジ色になっているすでに作業が終了している場所を選択し、確認する。  ・航空写真の画質が荒かったりするため、間違えて森などを建物と登録してしまっている  場所や四角く囲えてない場所の修正をする。  ・作業を完了したら、確認完了、未処理の場合は差し戻しで終了する。

Older Entries | Newer Entries