In this next edition of our OpenStreetMap interview series we speak with DW Innovation about SPOT, their tool for searching geospatial patterns in OpenStreetMap. They share how the project began, the challenges behind building it, and what they have learned since its launch.

1. Who are you and what do you do? What got you into OpenStreetMap?

We are DW Research & Cooperation projects. We research and experiment with new technologies in national and international innovation projects to get a clear picture of how journalism can benefit from those technologies.

In our research domain ‘verification’ we acknowledged that a very time-consuming process is the location verification of digital media. OpenStreetMap is a very interesting source of geolocation data as it contains non-commercial data that is relevant for geolocating digital media.

2. What is SPOT? What prompted you to create it? Why do we need a tool like this?

Imagine that you have to verify the location of a picture on which you can see a fountain and a church and a tower block within 60 metres of each other in the City of London. Google Maps won’t be able to help you searching for multiple entities at once, but in OSM you can actually search for geospatial information patterns.

The tool that we previously used for that is Overpass Turbo, however, it was rather complex to use for a lot of journalists. We decided to make searching in OSM easier and build a tool that can translate natural language prompts to search queries for geospatial patterns. The user won’t need to understand OSM tags and descriptors and can just prompt the system in their natural language, for example: ‘find a fountain and a church and a tower block within 60 metres of each other in the City of London’. The result will look like this:

3. What are the unique challenges involved in creating SPOT?

As we started in a world that was just being introduced to LLMs and training them for specific purposes it was quite complex to find the right open source model that would provide us with robust translation of natural language prompts to OSM search queries. We have developed a fine-grained automated benchmarking system that allows us to compare LLM models and measure the impact of fine-tuning.

Another challenge is the tagging system of OSM. We have developed our own descriptor-tag bundle index to try and make sure that we cover any way of searching for e.g. a public bin. We have also clustered visually similar entities, for example all kinds of train rails, due to our geolocation verification use case.

4. SPOT was launched at the end of 2024 launch announcement - what has the response been and what have you learned since then?

SPOT was received very well. The response from the journalistic and OSINT communities is very positive. We started with a Beta version that was not yet very stable. The early users saw the potential, looked through some bugs and provided us with very valuable feedback that allowed us to improve the application. Some, at first sight, minor issues led to insight that created structural changes in the system. Today, we have a well working, stable version that we can build on.

We are still learning that it is not easy to run well engaged open source projects. Building something, making it available for free and asking for input from like-minded is not necessarily the recipe for success. Also free products need to be marketed, also open source projects need to be well-managed and need Product Managers and Product Owners to thrive. We would be very happy to get more engagement from the OSM community, so if you can share the secret for that with us, we’d be much obliged!

5. Recently OpenStreetMap celebrated 20 years. Where do you think the project will be in another 20 years?

Phew, I was never so good at looking into the future. I guess we’ll see the urge and necessity to work on digital sovereignty in the near future. Implementation of that will take a bit. OSM can serve as a great example of how a society can build and own data and applications. OSM could possibly also use this momentum to make a leap and lead the way as a platform independent from state or big tech.

And of course, we would love OSM to be easily searchable for geospatial information patterns by everyone ;)

A big thank you to the team at DW Innovation for sharing their insights on SPOT and their work at the intersection of journalism, verification, and open geodata. We’re excited to see how SPOT and the wider OSM community continue to grow and collaborate in the years ahead.

Forward!

Ed and the OpenCage team

Please let us know if your community would like to be part of our interview series here on our blog. If you are or know of someone we should interview, please get in touch, we’re always looking to promote people doing interesting things with open geo data.

Como corrigir o nome de uma rua na aplicação CNEFE

Corrigir um nome de rua usando a aplicação CNEFE – Logradouro é um processo simples e direto, integrando os dados oficiais do Instituto Brasileiro de Geografia e Estatística com o mapa colaborativo do OpenStreetMap.

Veja o passo a passo:

1️⃣ Escolha a área no mapa Acesse a aplicação e navegue pelo mapa até a cidade ou bairro desejado. Você pode usar o zoom e arrastar o mapa para localizar a região onde deseja verificar os nomes das ruas.

2️⃣ Use o filtro “Rua” No painel de filtros, selecione a opção Rua. Isso fará com que a aplicação mostre apenas os logradouros classificados como ruas, facilitando a identificação de divergências entre o CNEFE e o OSM.

3️⃣ Escolha o editor A aplicação permite abrir a edição diretamente em um editor do OSM. Você pode escolher, por exemplo:

Editor iD (no navegador) JOSM (editor avançado para desktop)

Selecione o editor com o qual você já trabalha.

4️⃣ Selecione a rua a ser corrigida No mapa, clique sobre a rua que apresenta nome incorreto ou divergente. Compare o nome exibido no OSM com o nome oficial disponível na base do CNEFE.

5️⃣ Faça a correção No editor escolhido:

Selecione o trecho da rua No campo name, apague o nome incorreto Cole o nome oficial correto conforme indicado no CNEFE Verifique se não há abreviações indevidas ou erros de grafia

Exemplo: Se no OSM estiver “R. C. J. Silva” e no CNEFE constar “Rua Coronel João Silva”, atualize para o nome completo correto (seguindo as boas práticas da comunidade).

6️⃣ Envie a atualização Após revisar a edição: Salve as alterações

Escreva um comentário claro no conjunto de alterações (ex: “Correção de nome de rua conforme CNEFE 2022”)

Envie para o OpenStreetMap Pronto. O nome será atualizado no mapa colaborativo.

✅ Boas práticas Sempre confira se a rua selecionada corresponde exatamente ao logradouro do CNEFE.

Evite alterar nomes se houver sinalização local divergente — nesses casos, vale validar em campo. Mantenha o padrão adotado pela comunidade do OpenStreetMap no Brasil.

Assim, cada correção contribui para um mapa mais preciso, padronizado e útil para todos.

Correção de Nomes de Ruas no Openstreetmap. Aplicação CNEFE/CENSO2022.

https://cnefe.mapaslivre.com.br/logradouro/#map=5/-8.75479/-48.66943

‘De Wasvrouwen’ is een beeld van Carla Rump in Groet, Noord-Holland.
Link naar de locatie met tags op OSM.
Het beeld is een creatie van Carla Rump.

多言語表記のタグ付けを考える(パート2: 編集合戦編)

2026-02-01に’さくらインターネット Blooming Camp’で行われた「マッパーズサミット2026」での発表内容の「編集合戦編」です

パート１: OSMの基礎知識編

この記事は「基礎知識編」の続編です

必ず「基礎知識編」を見てから「編集合戦編」へ進んでください

• パート１: OSMの基礎知識編

パート2: 編集合戦編

ここからは、OSM編集で実際に起きた「編集合戦」について説明します。

パート１を見ていない方は、パート１: OSMの基礎知識編 を先に見ください

事件は「渋谷スクランブル交差点」で起きました
- ウェイ: 渋谷駅前交差点 (1335178864) “バージョン #6” 2025-07-30

この交差点は英語圏では “Shibuya scramble crossing”として世界的に認知されており、インバウンド観光客の目的地ともなっています
- 渋谷スクランブル交差点

訪日客が”Shibuya scramble crossing”を目的地にした場合、数多ある渋谷周辺の’交差点’の中からどうやって”Shibuya scramble crossing” だと確信することができるでしょうか？
交差点にある「案内標識」の「国際表記名=Sybuya Sta.」がOSMに入力されていれば,日本語を解さない人でも「Sybuya Sta.」と表記された場所が「Shibuya scramble crossing」だと確信することができます

• ここでは、OSMwikiの「一般的な名称以外は、派生名に入れてください」に従い、国際表記部分を int_name=Sybuya Sta. と入力します
  • 「一般的な名称以外は、派生名に入れてください」@osmwiki:名称キー

引き続き「ウェイ: 渋谷駅前交差点 (1335178864) “バージョン #6“」のマッピングを見てみます

「name = 渋谷駅前交差点」となっています

• 実際の表記は「渋谷駅前」なので、現物のとおり name=渋谷駅前 とし、交差点を削除します
  • 「存在しないものには名称をタグ付けしないでください」@osmwiki:多国語の名称
  • 「名前に説明を組み合わせて名称を作らないでください」@wiki/JA:名称#名称で説明しない
• OSMwikiに「現地語名称は言語明示サブキーと重複させてください 」とありますが、
  name=渋谷駅前としたことにより、name:ja と一致しなくなりましたが、下記の理由により、name:jaは変更せずにこのままとしました
  • すでにwikidataタグが付けられており、name:XXがロック状態になっているため
  • name:XXのソースが不明。ひょっとすると現地のどこかに表記があるかもしれないため

int_nameをマッピングしたところ、２～３日後に int_name が消されました。
- 「ウェイ: 渋谷駅前交差点 (1335178864) “バージョン #7“」

• int_name= を消すことは OSMwikiの記述に違反することになります
  • 「他の名前はすべて、派生名に入れてください」@osmwiki:名称#名称キー

また、name:enが name:en=Shibuya Sta.に変更されてしまいました

• name:en=Shibuya Sta. に変更することは、OSMwikiに違反することになります
  • 「現地語名称は言語明示サブキーと重複させてください 」@wiki/JA:多国語の名称#言語明示タグによる複数回の名前付け
  • 「略称は使用しないでください」@wiki/JA:名称#略称
  • 「省略しない」@wiki/JA:名称#略称
  • 「一般的な名称以外は、派生名に入れてください」@osmwiki:名称キー

ちなみに、すでにwikidataタグが付けられており、name:enはロック状態になっていいます。

wikidataタグがあるにもかかわらず’name:en’を改変しても意味はありませんし、OSMデータベースに不要なごみデータを蓄積されるだけです。（データベースの保守は無料ではありません）

無意味な編集合戦はやめましょう。

OK. Last year I wrote a short guide on mapping Indian addresses but I lost it in my tiny pursuit to delete myself. Today I suddenly came across the fact that the guide was actually used by mappers and, hence, as a result I am now writing this post to become a replacement for that old guide. Since this is a new one, I don’t want to just rehash the old stuff and instead this time I am going to take a simple problem and show how I would solve it from scratch.

A1, Tower 2, Sector 11, RK Puram, South West District, Delhi, India

A problem very similar to this one came up in OSM India’s XMPP channel today. So, how does one go about mapping this address?

As it’s usually the case we can ignore the district, state, and country part as they are all very well mapped in India. This leaves us with everything upto RK Puram.

If you are thinking that something as big as RK Puram should surely be already on the map then you are wrong; In my “career” I have actually seen larger areas without any nodes for them. So we will in fact check if it’s already on the map and, guess what, it actually is already mapped as a suburb, so that’s one less step for us! I should mention that in OSM there are three “neighbourhood” levels below the district: quarter, suburb, and neighbourhood in decreasing order of size. In most cases suburb and neighbourhood should be enough for you, but it is important to be aware of quarter for special situations.

Now let’s check for Sector 11. As of writing this, Sector 11 isn’t on the map. So I will put a neighbourhood node at the approximate centre of Sector 11. (Remember that neighbourhood is smaller than suburb.) We are making good progress.

Now let’s take care of Tower 2. It’s actually specifying a particular building, unlike the previous steps which were about specifying the area in which the building lies. In this case it should be “Tower 2” for housename and “Sector 11” for place. It’s important to specify the place because it could be the case that “Sector 45” node is actually closer to the building.

A small interjection: when mapping a building try to choose between housename and housenumber or place and street logically. If your address is “36, Shivaji Marg” then please please use 36 for housenumber and Shivaji Marg for street. If you do it incorrectly then there’s a 90% of divine punishment from OSM gods.

OK. The building is done. Now all you have to do is to add A1 to the unit tag as a separate node inside the building. Note that the A in this case does not refer to a block and so it should not be separated from the 1. Another important point is that even though A1 is referred to as housenumber in common language, in OSM it isn’t actually a housenumber since housenumber/housename are reserved for building. A1 is just a unit number which means that it is a part of the building. (In case you haven’t realized it yet, the given address was for an apartment.)

I forgot to mention but blocks are somewhat of a controversial topic. My method is usually to retain the blocks in housenumber if they are simple (such as the 1 in “1/265”) or move them into “place” if they are more complicated (like the Pocket E in “36, Pocket E”).

OK. Let’s see if you were reading carefully. Tell me how you would map

1/26/65EB, Gali Shanti, Near Phoole Wala Mandir, Chandni Chowk, Old Delhi

Were you able to do it? Here’s my answer:

Old Delhi is probably already mapped, Chandni Chowk would be a neighbourhood, I would ignore Phoole Wala Mandir, I would add Gali Shanti to the name of highway, then finally for the building I would add 1/26/65E as housenumber and Gali Shanti as street. Did you notice that I never actually told you that letters like E are allowed in housenumber? By that I wanted to show that this guide probably does not contain comments for each and every case, but it should work for the majority of cases. If you come across a difficult problem, then your best bet is always OSM Wiki. Just look it up!

This post was first released on my website with 💜 under CC BY-NC-SA 4.0.

本系列编辑主要修复了部分住宅楼的过大幅度偏移，以及一些误标记的绿化。问题区域主要在星塘街以东，为方便起见，以东西向道路作阶段性的分割。

记录

2026/2/24已完成修复兆佳巷以北

2026/2/25已完成修复中新大道东以北

2026/2/26已完成修复港田路以北

A few months ago, I worked on a new project: the OSM Tagging Schema MCP — a Model Context Protocol (MCP) server built for AI assistants and LLM applications that interact with OpenStreetMap tagging data.

It serves as a bridge between AI systems and the official OpenStreetMap tagging schema, allowing agents to validate tags, query values, search presets, and suggest improvements using the structured knowledge from the @openstreetmap/id-tagging-schema library.

The current 3.x release is technically stable — all tools and endpoints work reliably without errors — but it should still be considered experimental. Active development on version 3 has ended; for now, I only maintain it through dependency updates.

The next major step will be version 4, a complete rewrite developed with AI-assisted coding, focusing on a cleaner architecture, long-term maintainability, and deeper MCP integration.

You can try the service live here: mcp.gander.tools/osm-tagging.

I invite you to experiment, test, and share feedback — your ideas and suggestions are always appreciated: gander-tools/osm-tagging-schema-mcp discussions

Before

After

Whether you’re passionate about maps, data, or shaping the future of  OpenStreetMap (OSM), the community is always looking for your inspiring ideas! Why not sharing them during State of the Map 2026?

The call for participation of SotM 2026, taking place in Paris, France, on August 28 – 30, 2026, is now open! The programme committee is ready and waiting, eager to unwrap your submissions for talks, workshops, and panels. These sessions aren’t just part of the conference; they’re its beating heart, driving conversations and sparking ideas that resonate worldwide. Presenting your work, projects and ideas at SotM is also a great way to get in touch with the wider OSM community.

Tracks

Sessions can be submitted for the following tracks:

• OSM Basics – Information dedicated to newcomers
• Community and Foundation – Bringing people together, working group experiences, strategies & vision
• Mapping – All about making the mapping easier and better
• Cartography – Your ideas on how to create good-looking presentations of the OSM dataset
• Software Development – Software for processing and editing data
• Data Analysis & Data Model – Reflections about the OSM data, its model and analysis of quality and completeness
• User Experiences – Stories of using OSM and its data as a user
• Education – How you use OSM in an educational context

If your submission doesn’t seem to fit into one of these tracks, don’t worry – as long as it is clearly related to OpenStreetMap, you’re perfectly fine if you simply choose the track that feels to fit best.

OSM Science (Academic Track) at SotM 2026

In addition to this general call for participation, there will again be a proper academic track with a separate CfP, which will be announced later. So, if you’re knee-deep in the captivating world of OpenStreetMap, stay tuned for the official call: The working group is eagerly awaiting the most riveting insights and groundbreaking results from your studies. Get your research hats on, gather your data, and prepare to submit the best of your studies.

Timeline and Deadlines

• 27 April 2026 23:59:59 UTC: Deadline talk, workshop and panel submissions
• End of May 2026: End of review phase, speakers will be informed, schedule published
• 28-30 August 2026: State of the Map in Paris, France

For more information on the above track categories, submission requirements and rating criteria, please visit the complete call for participation and the submission guidelines on the SotM website.

Stay tuned for more news about the State of the Map 2026! See you later this year in Paris, France, and online!

The State of the Map Working Group

Do you want to translate this and other blogposts in your language…? Please email communication@osmfoundation.org with subject: Helping with translations in [your language]

The State of the Map conference is the annual, international conference of OpenStreetMap, organised by the OpenStreetMap Foundation. The OpenStreetMap Foundation is a not-for-profit organisation, formed to support the OpenStreetMap Project. It is dedicated to encouraging the growth, development and distribution of free geospatial data for anyone to use and share. The OpenStreetMap Foundation owns and maintains the infrastructure of the OpenStreetMap project, is financially supported by membership fees and donations, and organises the annual, international State of the Map conference. Our volunteer Working Groups and small core staff work to support the OpenStreetMap project. Join the OpenStreetMap Foundation for just £15 a year or for free if you are an active OpenStreetMap contributor.

OpenStreetMap was founded in 2004 and is an international project to create a free map  of the world. To do so, we, thousands of volunteers, collect data about roads, railways, rivers, forests, buildings and a lot more worldwide. Our map data can be downloaded for free by everyone and used for any purpose – including commercial usage. It is possible to produce your own  maps which highlight certain features, to calculate routes etc. OpenStreetMap is increasingly used when one needs maps which can be very quickly, or easily, updated.

finding myself to osm was something I couldn’t understand at the time. Now with an open eye, in my field of water engineering introduced to geographical information system. I love it here my journey begins now mapping take me overseas. 😊

I successfully put Novato Baylands Point Blue Conservation Science as a pin on the map. However, I have not had success with editing the directions that maps provides to get you to the site. The directions still route you past the facility, rather than stopping right at the facility. They should tell you to go down Aberdeen Rd, and then the location is on your right. Thanks for any assistance with editing the route.

I’m new to editing OpenStreetMap, so this is my first change! I noticed that most neighbourhood areas in Lethbridge, my local city, don’t have a name shown in OSM. However, they’re all neatly shown on an official 2024 map from the government of Lethbridge, so I used it as a source. I did notice that some areas are already named in other ways, but I couldn’t find the item that holds the name. This induced visual clutter by doubling some names (those of the industrial parks, Copperwood, and seemingly Paradise Canyon), but I still added the names to the neighbourhood areas for consistency anyways. If anyone around knows how to get rid of this without removing the naming consistency, it would be great if this slight issue could be resolved. I haven’t actually tested the map yet, since I just uploaded the edit, but if what I’m describing is actually a problem, please help? Anyway, I intend on updating and adding a lot of things to Lethbridge (like adding addresses and new buildings) in the near-ish future, so it’d be fun to get to know the local OSM community.

Code for Harimaの定例会で自分が表明したことで議事録に載せてますが、こちらに転記しておきます。

数ヶ月ほど前にあったCode for Harimaの定例会で、OSMを利用した万博マップに対して自分が「大阪万博には、赤字補てんのための公的資金投入やカジノありきの計画、パビリオン建設工事費未払問題などさまざまな政治的問題があり、それに加担するような活動は良くない」という発言したところ、参加していたOpenStreetMap Foundation Japanの某氏は「万博は政治的じゃない」と発言したことに驚いた出来事がありました。

OSMFJの人がそういう発言をするのであれば、自分は逆に 政治的なOpenStreetMap のプロジェクトをやろうと思いつきました。

自分が個人的にぼちぼちやるので、別になにかあるというわけではありませんが、とりあえず表明ということで書いておきます。ひとまず、次の2つを考えています。

1. 反人種差別のためのマッピング
2. 敵対的建築物(Hostile architecture)を記録するマッピング

1. 反人種差別のためのマッピング

OpenStreetMaps USで、社会的公平性のために人種差別に関する地物をマッピングして、wikidataとリンクさせて可視化するというプロジェクトがあります。

• United States/Racism - OpenStreetMap Wiki

アメリカでは、黒人奴隷や南軍、KKK関連の地物をマッピングしています。日本では、戦前、戦中に韓国や中国から強制労働で多数の人が連れて来られて、炭鉱や建設などに従事させられました。

その労働は過酷で、命を落とす人もいたので慰霊のための慰霊碑が建てられていたりします。たとえばこれとか。

• 神戸電鉄朝鮮人労働者の像 - Wikipedia

こういうものを記録していきます。群馬の森の朝鮮人慰霊碑が歴史修正主義者のクレームにより撤去されるという事態も起こっているので、記録は残さないとと思っています。

• 「群馬の森」朝鮮人追悼碑の撤去…平和を願う関係者の無念を映画化 - RKB毎日放送

2. 敵対的建築物(Hostile architecture)を記録するマッピング

敵対的建築物は直訳ですが、日本語では「意地悪ベンチ」「排除アート」と呼ばれているものです。

排除アートは、行政がホームレスや若者がたむろさせないために、ベンチを座りにくくしたり寝られないように手すりをつけることや、人が溜まりやすいスペースに意味不明なアートっぽい（アートではない）オブジェを置いて、そこに滞留できないようにすることです。

• 〈人を座らせないベンチ〉東京・新宿の“意地悪ベンチ”に批判続出！ 一方、下町では真逆の試み…ベンチだらけの商店街を取材 - 集英社オンライン - ニュースを本気で噛み砕け
• RedditのHostile Architectureサブレ
• 排除アート - Wikipedia

ふと気になってOSMのタグを調べたら、そのものズバリ「Hostile architecture」のタグがproposalに出てたので、この動きを推進するために、これらをマッピングします。

• Hostile architecture - OpenStreetMap Wiki
• Proposal:Hostile Architecture - OpenStreetMap Wiki

redditの写真を見れば排除アートがどんなものかわかりますが、広がっている問題については可視化しないとわからない人がいるので、どんどんつけて可視化したいと思ってます。

ということで、時間ができたときに自分はぼちぼちやっていきます。興味がある人がいれば連絡をください。

• https://tools.geofabrik.de/
• https://hdyc.neis-one.org/
• https://osmose.openstreetmap.fr/

12/02/2026-18/02/2026

Mapping

• Comments are requested on the proposal bicycle_parking=absent. This tag aims to document that no bicycle parking is available around a feature, for example a shop or station, making such gaps in infrastructure discoverable in data analyses. Related discussion is also taking place on the forum.

Community

• Clifford Snow introduced the ‘Safe Routes to School’ initiative, which supports families who want their children to walk or cycle to school in a safe way. The project focuses on identifying the most suitable routes and collaborating with local authorities to make those routes safer. The team is currently looking for additional volunteers to improve the data. Those who would like to contribute can join the #safe-routes-to-school channel on the OSM US Slack.
• OpenCage has published an interview with Nicolas Collignon, CEO of Kale AI, a company developing urban delivery routing solutions powered by OpenStreetMap.
• Anne-Karoline Distel showed how to add information about what is or was quarried at a quarry in OpenStreetMap, noting that such data can be valuable for historical research, whether in industrial, social, or even church history.
• Marcelm005 has proposed a project to map the Lincolnshire ER Routes, emergency routes that enable people to quickly evacuate from flood-prone areas.
• rtnf is trying to learn how OSM tile servers work.
• The OpenStreetMap US community is currently deliberating on the most effective method for querying OpenStreetMap objects based on their geometric shapes.

OpenStreetMap Foundation

• The next OSM Foundation Board meeting will take place on Thursday 26 February 2026 at 13:00 UTC.The meeting will be accessible through the video room.The topics to be covered are:
  • Chairperson’s report
  • Secretary’s report
  • Treasurer’s report
  • 2026 board face-to-face meeting update
  • French cadastre changes and release of code updates for ‘OSM components’ on GitHub
  • Creation of an OSMF Coinbase account for BTC donations
  • Potential statement/policy for OSMF’s participation with other parties in proposals for EU-funded projects, and related topics:
    • Draft blog post: OSMF approach to EU-funded project collaborations
    • Potential OSMF participation in Horizon Europe CSA (GeosTeX)
    • European Institute of Technology (EIT) communications
    • 2026 Sovereign Tech Agency call for tenders
  • Request for comments for GERS as an OGC Community Standard
  • Guest comments or questions.
• The Marche Region (Italy) reported ► about its recent entry among the supporters of OpenStreetMap as a ‘Silver Member’. This is the first time that an Italian public body has officially recognised the usefulness of OpenStreetMap and decided to actively contribute to its financial support.

Local chapter news

• OpenHistoricalMap has kicked off their first donation drive to help fund technical development and operations.

OSM research

• A Danish survey conducted in January 2026 found that in Denmark, OpenStreetMap contained approximately 20,878 km more paths, footways, and tracks than the official Danish road network dataset, GeoDanmark Vejmidter. The survey was carried out by the Danish organisation GeoDanmark.
• A new study published in Nature Communications uses OpenStreetMap land use and AOI data to help classify 110 million buildings across 109 Chinese cities, demonstrating how open, community-mapped data supports national-scale urban inequality analysis and evidence-based planning.

Maps

• kafked has presented his side project rename.world on Hacker News. rename.world is a MapLibre-based map where users can click any place and propose new names. Around 40,000 renames have already been submitted; the non-commercial project runs on SvelteKit, with self-hosted vector tiles, and is explicitly not intended for navigation.
• The Welikia project shows the native ecology of New York City (i.e. what it was before settlement), using OSM as base map. The project is maintained by the Urban Conservation team at the New York Botanical Garden.

OSM in action

• ^[1] At the News-Infographics-Analytics-Maps 2026 conference in Berlin, data visualisation journalist Ferdinand Holsten presented how the German news magazine DER SPIEGEL has built its own open-source mapping stack based on MapLibre and Protomaps. This allows DER SPIEGEL to host tiles for interactive maps independently of commercial services such as Mapbox. The presentation, which is now available as a video on media.ccc.de, outlines the workflow from data preparation to tile generation and the integration into an interactive storytelling. Ferdinand Holsten has kindly provided us with an automatic translation of the presentation into English.
• Jake Coppinger (UrbanSpectra) has published a map tracking community and government projects across a river catchment, utilising OpenStreetMap data (Sydney, Australia).
• rbb24, part of public service broadcasting in Germany, naturally uses ► OpenStreetMap, with correct attribution, in its reporting of locations.

Open Data

• HeiGIT reported that it has published new open and ready-to-use global risk assessment datasets, with the objective to simplify risk analysis by removing major technical barriers to data preparation. These datasets are designed for easy use with the risk assessment QGIS plugin and enable humanitarian stakeholders to conduct multi-hazard, evidence-based risk assessments to support anticipatory action.
• Xiong et al. have published a dataset, which contains a topologically connected representation of the European high-voltage grid (220 kV to 750 kV) compiled from OpenStreetMap data extracted with overpass turbo.

Software

• sylvester_aswin has introduced their project Map Frame, which allows users to generate minimalist map posters based on OpenStreetMap data. Any location worldwide can be selected and downloaded as a 4K PNG (3600×4800); the first poster is free, additional downloads cost one US dollar.
• Carlos Froh introduced OnRouteMap, a web tool that helps find petrol stations, supermarkets, snack bars, drinking fountains, and similar places along your uploaded GPX track.
• The solo developer thattechiedude, from Hudson Valley, has presented ROLLIN, a map platform rating locations from 0–100 based on six features such as wheelchair access, accessible toilets, and lifts. The project uses OpenStreetMap data, cross-references Google Places, and adds community verification, and offers a free API tier for developers.
• Terence Eden, the developer of OpenBenches, has recently implemented a login with OpenStreetMap function in OpenBenches.
• Ulf Rompe has developed ‘What Did You Do‘, a simple tool that shows the number of OpenStreetMap edits made by each software application within a certain period of time.

Programming

• Thomas de Wolff has introduced his Go library geo/osm on Reddit, offering fast parsing of OSM PBF files through handwritten protobuf decoding, optimised readVarint and readSint routines, and custom zlib decompression. The library can skip specific object types, generate file statistics, and extract geometries by region filter, making it suitable for building custom renderers.
• In response to recent Overpass API service instability, Matt Whilden has developed microcosm, a GitHub Actions script that retrieves a narrow slice of OSM data and updates it nightly.
• Andy Townsend discussed the difficulties encountered in setting up your own Overpass API server.

Did you know that …

• … you can zoom one-handed in Organic Maps?
• … you can easily submit a brand to the Name Suggestion Index project by using NSI Submit a Brand?
• … there is a Mastodon instance run by and for OpenStreetMap contributors that is funded by the OSMF?

Other “geo” things

• Emmanuel Mathot and Jonas Sølvsteen wrote on the Development Seed blog about the release of the ‘EOPF Sentinel Zarr Explorer’, a framework for spatial analysis based on Sentinel images. The cloud-based geospatial project is funded by the European Space Agency through the Copernicus Space Component programme, and was developed by a consortium led by Development Seed and EOX, with community outreach led by thriveGEO.

Upcoming Events

Country	Where	Venue	What	When
	Karlsruhe	Geofabrik, Amalienstraße 44, 76133 Karlsruhe	Karlsruhe Hack Weekend February 2026	2026-02-21 – 2026-02-22
	Belfast	School of Geosciences, Queen’s University Belfast	Belfast Mapathon	2026-02-21
		TAK Kadıköy Tasarım Atölyesi	OpenStreetMap Outdoor Editing	2026-02-21
	Toulouse	Artilect – 10, Rue Tripière – Toulouse	Rencontre OSM Toulouse	2026-02-21
	Kalyani Nagar	TomTom Pune Office, India	OSM Mapping Party at TomTom Pune, India	2026-02-21
		Atelier Vélo Utile	Rencontre OSM Saint-Brieuc	2026-02-21
	Mumbai	High Point restaurant, Lokhandwala Market, Andheri	OSM Mumbai Mapping Party No.7 (Western Line – South)	2026-02-22
			Missing Maps : Mapathon en ligne – CartONG [fr]	2026-02-23
	Saint-Étienne	Zoomacom	Rencontre Saint-Étienne et sud Loire	2026-02-23
	Olomouc	Přírodovědecká fakulta Univerzity Palackého	Únorový olomoucký mapathon	2026-02-24
		Online	Mappy Hour OSM España	2026-02-24
	Derby	The Brunswick, Railway Terrace, Derby	East Midlands pub meet-up	2026-02-24
	Berlin	Online	OSM-Verkehrswende #72	2026-02-24
	City of Edinburgh	Guildford Arms, Edinburgh	OSM Edinburgh pub meetup	2026-02-24
	Praha	Fakulta Elektrotechnická ČVUT v Praze	Missing Maps Mapathon na ČVUT v Praze	2026-02-25
	Hannover	Kuriosum	OSM-Stammtisch Hannover	2026-02-25
	Luxembourg	neimënster, Luxembourg & online	MSF Luxembourg hybrid Mapathon	2026-02-25
	Düsseldorf	Online bei https://meet.jit.si/OSM-DUS-2026	Düsseldorfer OpenStreetMap-Treffen (online)	2026-02-25
	Seattle	Seattle, WA, US	OpenThePaths 2026: Connecting People and Places Through Sustainable Access	2026-02-26 – 2026-02-27
	Essen	Fahrrad-Messe Essen, Halle 5, Show-Truck	Vortrag: Mitmachen bei OpenStreetMap, der Basis vieler Outdoor-Apps	2026-02-26
	Milano	Building 3A Ground Floor – Politecnico di Milano	PoliMappers Maptedì	2026-02-26
	Zürich	Meta Zurich Office	Mapillary: Celebrating 3 Billion Images	2026-02-26
		Online	Asamblea General Ordinaria – Asociación OpenStreetMap España	2026-02-26
	Santa Clara	Santa Clara University	Friends of MSF Mapathon	2026-02-26
			UN Maps Validation Friday Chat & Map	2026-02-27
	Essen	Fahrrad-Messe Essen, Halle 5, Show-Truck	Vortrag: Mitmachen bei OpenStreetMap, der Basis vieler Outdoor-Apps	2026-02-27
	Potsdam	Hafthorn	Potsdamer Mappertreffen	2026-02-27
	Ferrara	Cimitero monumentale della Certosa di Ferrara	Ferrara mapping party	2026-02-28
	Messina	Messina	Mapping Day @ Messina	2026-02-28
	नई दिल्ली	Jitsi Meet (online)	OSM India – Monthly Online Mapathon	2026-03-01
	Milano	Building 4A, Room Fassò – Politecnico di Milano	PoliMappers Maptedì	2026-03-03
	Salzburg	Bewohnerservice Elisabeth-Vorstadt	OSM-Treffpunkt	2026-03-03
	Lille	Salle Yser, MRES, 5 rue Jules de Vicq, Lille	Rencontre OpenStreetMap à Lille	2026-03-03
			Missing Maps London: (Online) Mapathon [eng]	2026-03-03
			iD Community Chat	2026-03-04
			OSM Indoor Meetup	2026-03-04
	Brno		Kvartální OSM pivo	2026-03-04
	Stuttgart	Stuttgart	Stuttgarter OpenStreetMap-Treffen	2026-03-04
			OSM US Mappy Hour: OpenHistoricalMap in North America	2026-03-04
		Online	OpenHistoricalMap in North America	2026-03-04
	Flensburg	Offener Kanal Flensburg	3. Open Data Day Flensburg	2026-03-05
			OSMF Engineering Working Group meeting	2026-03-06
	Gent	Wijgaard	OpenStreetMap meetup in Gent – Pre-VLA-congres editie	2026-03-06
		Hogeschool Odissee Hospitaalstraat 23 Sint-Niklaas	Vereniging Leraars Aardrijkskunde (VLA) conference 2026	2026-03-07
	Perth	Espresso Perk U Later	Social Mapping Sunday: Moort-ak Waadiny / Wellington Square Perth	2026-03-07
	Perth	Espresso Perk U Later	Social Mapping Sunday: Moort-ak Waadiny / Wellington Square Perth	2026-03-08
	Delhi		OSM Delhi Mapping Party No.27 (East Zone)	2026-03-08
	København	Cafe Bevar’s	OSMmapperCPH	2026-03-08
	London	Social Sciences Centre – Western University	Friends of MSF UWO Mapathon	2026-03-09
			Missing Maps : Mapathon en ligne – CartONG [fr]	2026-03-09
	Brno	Geografický ústav, PřF MUNI, Brno	Březnový brněnský Missing Maps Mapathon na Geografickém ústavu	2026-03-09
	臺北市	MozSpace Taipei	OpenStreetMap x Wikidata Taipei #86	2026-03-09

Note:
If you like to see your event here, please put it into the OSM calendar. Only data which is there, will appear in weeklyOSM.

This weeklyOSM was produced by MarcoR, MatthiasMatthias, PierZen, Raquel IVIDES DATA, Strubbl, Andrew Davidson, barefootstache, derFred, mcliquid.
We welcome link suggestions for the next issue via this form and look forward to your contributions.

包含建筑物、森林。之前陆陆续续修复了一些，不过都是游击式地修复，没有系统地记录过。现在有时间捡起这件事了，先在这里留个坑吧。

……不要给房子加layer标签来逃避冲突检查器的检查。

26/2/21

Taking a break for 1 week because of ramadhan and installing gentoo as my main system.

I have a large set of photographs I made while running. They are geotagged, as I took them with my phone camera. The compass direction is completely unreliable, but lat/lon is more trustworthy. I thought it would be an interesting experiment to extract greenery like grass and trees from these photographs. It can be a useful addition for creating routes that are more pleasant to walk, since the eye-level point of view is not available in OSM. As this is based on my personal photographs, it has the additional benefit of recommending routes that I tend to use. The first challenge I encountered is that out of a few thousand photographs, only a handful were taken during the daytime. After deduplicating and dropping all photos that contain no greenery, this becomes a relatively small set of waypoints. I decided not to extrapolate additional points along OSM ways to keep the dataset small and avoid adding misleading info. The greenery detection works well enough with the SegFormer model, although it is somewhat slow locally. My plan is to select waypoints from this dataset before calling OSRM. This way I get routes that are more enjoyable to walk and run, but are generally longer than the default shortest route. You can find my dataset on Kaggle.

A few quick notes on some changes I made to OSM based on local knowledge.

1. Changed the point for the Riverside Centre building to reflect that it is now a Builder’s Corner hardware store.

2. Added a point for the nearby Hole in the Wall Centre

3. Defined an area for the Somerset Lofts apartment complex and added some details for it.

I’ve recently begun contributing street-level imagery on Mapillary and Panoramax in my local area. I figured that my dash cam was already recording anyway, so if it could be of use to anyone, why not share it?

Contributing to Mapillary was very easy; since my dash cam has an integrated GPS that encoded its data into the video file, I could just upload the video to Mapillary and their website would turn it into an image sequence. Panoramax requires you to preprocess the video into geotagged images yourself, which made it hard to contribute to. Some cameras can be configured to save periodic images instead of videos, but that didn’t work for me because I still needed the dash cam to work normally as a dash cam first and Panoramax instrument second. It took me a while to figure it out, so I’m writing this blog post to hopefully help out the next guy in the same situation.

The task involves four basic steps. I scripted a solution that works specifically for my dash cam model (Garmin 47) and operating system (Linux). If Panoramax continues to grow, I imagine that separate scripts could be written for each step to mix and match for different camera types and computing environments. The steps are:

1. Extract the raw GPS data from the dash cam video clip(s)

2. Along the GPS trace, create a set of evenly-spaced points

3. Extract images from the video occurring at the evenly-spaced points, and

4. Add the GPS and time data to the image files

One could go even further and automatically upload the images to Panoramax straight from the terminal, but that’s beyond my coding abilities.

Let’s take a look at each step in detail:

Step 1 - Getting GPS data from the video

Thankfully, Garmin makes this relatively easy to do with exiftool. If you open the terminal in the directory with the video clips and run the command

exiftool GRMN<number>.MP4

The output will contain a warning:

Warning : [minor] The ExtractEmbedded option may find more tags in the media data

So we can modify the command into

exiftool -ee3 GRMN<number>.MP4

Now exiftool will output all the same information as before, as well as a bunch of the following

Sample Time                     : 0:00:58
Sample Duration                 : 1.00 s
GPS Latitude                    : XX deg YY' ZZ.ZZ" N
GPS Longitude                   : UU deg VV' WW.WW" W
GPS Speed                       : 11.2654
GPS Date/Time                   : 2026:02:13 22:24:45.000Z

Jackpot! Now we can redirect the output to a file and get our GPS coordinates. We need to have a file saved in the working directory to tell exiftool how to format the data. So I saved the following as gps_format.fmt:

#[IF]  $gpslatitude $gpslongitude
#[BODY]$gpslatitude#,$gpslongitude#,${gpsdatetime#;DateFmt("%Y-%m-%dT%H:%M:%S%f")}

Now we pass that to exiftool to only print the metadata we’re interested in. We’ll also put > gps.tmp to save the output to a file:

exiftool -p gps_format.fmt -ee3 GRMN<number>.MP4 > gps.tmp

And we’re done! Now we have the raw GPS information out of the video and into plain text.

Step 2 - Turn the GPS data into evenly spaced points

To do this, I use python to linearly interpolate between GPS points approximately 3 meters apart. And I do mean very approximately: instead of doing a proper distance calculation, I just eyeball how many meters are in a degree. One meter is very roughly about 0.000009° of latitude. Since one meter is a larger portion of a degree near the poles, it needs to be adjusted based on the latitude. I blindly use the latitude of the first point of the sequence and assume it doesn’t change enough over time to matter.

from math import cos, radians
cosd = lambda x: cos(radians(x))

scale_lat =  1 / 9e-6
scale_lon = (1 / 9e-6) * cosd(lat0)

Now it is easy to use the Pythagorean Theorem to estimate the distance between two points:

dx = scale_lon * (lon1 - lon0)
dy = scale_lat * (lat1 - lat0)
dist_between_points = (dx**2 + dy**2)**0.5

Recursively find this distance for each pair of points along the GPS trace. Also keep a running tally of the total distance traveled. For example, consider the following data after you stop at a red light, sit for a while, and then keep going:

Pt | Dist | Tot
A  | --   | 0
B  | 10   | 10
C  | 6    | 16
D  | 2    | 18
E  | 0    | 18
(sit at the red light...)
Q  | 0    | 18
R  | 1    | 19
S  | 3    | 22
T  | 7    | 29
U  | 11   | 40
V  | 14   | 54
(and so on)

Suppose you want image spacing of about 3 meters (about 10 feet or half a car length). So you want images at 0, 3, 6, 9, 12, 15, …, and so on. We can take point A as our first point, but we need to interpolate between GPS points to find evenly-spaced points. I’ll use the notation X -> Y N% to mean “interpolate N% from X to Y.” Then to find our desired points, we need:

Pt | Formula
0  | A
3  | A -> B 30%
6  | A -> B 60%
9  | A -> B 90%
12 | B -> C 33%
15 | B -> C 83%
18 | D
21 | R -> S 67%
24 | S -> T 29%
27 | S -> T 71%
30 | T -> U  9%
etc...

Since Garmin takes GPS measurements once per second, this is a convenient way to determine at exactly what time each new point occurred. For the point 60% from A to B, it’s just the GPS timestamp of A plus 0.60 seconds. For the latitude and longitude of the interpolated point, we can just interpolate the latitude and longitude coordinates separately. 3 meters is not even close to far enough for great-circle paths to matter. So e.g.

lerp = lambda a, b, x: (1 - x) * a + x * b

lat_interp = lerp(latA, latB, 0.6)
lon_interp = lerp(lonA, lonB, 0.6)

# And so on for each interpolated point

Save this output to a file (I call mine processed_points.csv), and you’re done with step 2!

Step 3 - Extract images from the video

It is possible to extract a single frame of a video using ffmpeg. The time should be a decimal number of seconds after the start of the video to exactly three decimal places.

ffmpeg -ss <time> -i <video>.MP4 -frames:v 1 output.jpg

By default, ffmpeg compresses the images quite a bit. It was enough that I could notice a quality difference when I put a paused frame of the video side-by-side with an extracted image. We can force ffmpeg to improve the quality with q:v (number). A smaller number here produces a higher quality image at the expense of file size and processing time. I’ve settled on a value of 3, but feel free to play around with this to get the quality or file sizes you want.

ffmpeg -ss <time> -i <video>.MP4 -q:v 3 -frames:v 1 output.jpg

ffmpeg will print a bunch of text to the console that we don’t care about. To avoid flooding the screen, use the -hide_banner and -loglevel options to reduce (but not completely shut up) the amount it outputs to the console:

ffmpeg -ss <time> -i <video>.MP4 -q:v 3 -frames:v 1 -hide_banner -loglevel fatal output.jpg

Since you are going to extract many images, you’ll have to use this command in a loop with a bunch of variables that change from iteration to iteration, e.g.

ffmpeg -ss $(printf "%.3f" "$time") -i "$input_dir""/DCIM/105UNSVD/GRMN""$num"".MP4" -q:v "$jpeg_quality" -frames:v 1 -hide_banner -loglevel fatal "$output_dir"/"$num""-""$(printf "%04d" $img_num)"".jpg"

My naming convention produces file names of the format video number-image number.jpg. So for example, the 25th image extracted from GRMN4567.MP4 would be named 4567-0025.jpg.

And we’re almost there! Now we just need to put the metadata from step 2 into the images we just generated.

Step 4 - Add the GPS and time metadata to the images

You can write tags to files using exiftool using the format:

exiftool -<key>=<value> <file name>.jpg

You can add multiple tags in a single line.

exiftool -<key1>=<value1> -<key2>=<value2> <file name>.jpg

Note that exiftool only supports specific keys, so it won’t write the metadata if it doesn’t know what the key is. It creates a new image by default, so to avoid duplicating each image, add:

exiftool -overwrite_original -<key1>=<value1> -<key2>=<value2> <file name>.jpg

This will write a line to the terminal to confirm after every single image. To avoid that, redirect the output to /dev/null. This tells the terminal to throw the output into a black hole, or the wardrobe to Narnia, or anywhere else besides the terminal.

exiftool -overwrite_original -<key1>=<value1> -<key2>=<value2> <file name>.jpg 2> /dev/null

For Panoramax to accept your images, you need all of the following tags:

-gpslatitude=45.6789
-gpslongitude=-123.456789
-gpslatituderef=N
-gpslongituderef=W
-datetimeoriginal=2000-01-02T03:04:05

If you are missing these, Panoramax will reject your image. Note that the latitude and longitude ref tags are necessary because exiftool doesn’t understand negative coordinates as being in the southern or western hemispheres. You have to provide them separately for the GPS data to be read correctly. If you forget to add them, Panoramax may accept the image but put it in the wrong place. The date and time should be given in ISO 8601 format. If you don’t specify a time zone, Panoramax will assume local time and automatically convert it to UTC on their site.

You can theoretically add any tag in the exif specification. Some ones I like for Panoramax are:

-subsectimeoriginal=067
-author=FeetAndInches
-make=Garmin
-model="Garmin 47 Dash Cam"

The SubSecTimeOriginal field is important for getting Panoramax to put your sequence in the right order. Since the images come from a dash cam, speeds of 10-20 m/s are common, so multiple images are taken per second of video. The DateTimeOriginal tag does not preserve fractional seconds (even if you provide them when writing the tag), so several pictures would be recorded as the same time and Panoramax would have to guess their order. Note that this needs to be provided as an integer string after the decimal point. So for a time of 51.328 seconds, you would write -subsectimeoriginal=328. For a time of 51.1 seconds, you would just write -subsectimeoriginal=1. For a time of 51.001 seconds, you would need to include leading zeroes as -subsectimeoriginal=001.

If you don’t use the SubSecTimeOriginal tag, you can still get Panoramax to show your images in order if you use a suitable file naming convention. You can open the sequence on the website and select the option to sort by file name.

The author tag is just nice to attribute that it’s your image even if it gets shared outside Panoramax. The make and model tags help fill in some of the camera information on Panoramax and helps determine your GPS accuracy, which is used to determine the image’s quality score.

You can do step 4 in the same loop as step 3. Since the coordinates and time will change for each image, the command will look messy like:

exiftool -overwrite_original -gpslongitude=$lon -gpslatitude=$lat -gpslatituderef=$ns -gpslongituderef=$ew -datetimeoriginal=$timestamp -author="$exif_author" -subsectimeoriginal="$subsec" -make="$exif_make" -model="$exif_model" -usercomment="$exif_comment" "$output_dir"/"$num""-""$(printf "%04d" $img_num)"".jpg" > /dev/null

Closing Notes

This post explains the basic principles of how to turn a video into usable images on Panoramax. I plan to write a second post going into the 201 level - things like how to deal with missing a single GPS measurement, duplicated measurements, getting sent to Null Island, how to detect erroneous data, using the videos immediately before and after to interpolate better at the edges, recursively doing this for multiple video clips, etc. But for now, I hope this has been useful to you.

If anyone is interested, I can share the entire scripts that I use right now. They’re a little buggy, only partially commented, and occasionally require some babysitting to make sure they work properly. But if something is better than nothing and you are willing to try and deal with someone else’s amateur code, please let me know.

Thanks for reading,

FeetAndInches

• I spent some time today improving the map data in my local area using the iD editor. As a local, I noticed that several roads were untracted

• added roads but i got confused while selecting presets- then i realised the more i do mapping, the better i will get with using presets. Each preset serves a unique purpose.

• Few weeks ago i spent time mapping my school in my city, i was soo fun- just wish they could use more updated satelite image.

Two years ago or so I started the OSM XRAY project, later I wrote about it in this blog post. Since then I have renamed this project to “OSM Spyglass” and I have kept working on it on and off.

At the State of the Map Europe 2025 in Dundee I gave a talk with the title “Everything Everywhere All At Once” about this project. You can see the video on Youtube. This got some people excited about the project, there is even some talk about putting the tool on OSMF infrastructure. Until this comes about the tool is now hosted at spyglass.jochentopf.com.

I am finally getting around to writing some more about what’s been happening since my first announcement and since the talk.

User Interface

I keep fiddling with the user interface. Optional globe view (not much to do for me now that Maplibre supports that out of the box), map is now resizable (horizontally), display of city names in some zoom levels, improved pop-up menus for keys and tags, and much more. Generally the UI has been getting faster and more reliable.

There are still some bugs to fix and plenty of possible improvements. And I’d be happy about feedback and ideas. Its quite a lot of information we are trying to show here in limited space, so good ideas on how to do that are needed.

Caching

In the first blog post I wrote about some caching that I implemented in the database. That did work but it turns out it is pretty useless. The user wants to access the newest data anway and we can keep up with minutely updates (at least in larger zoom levels), so I removed the caching completely for vector tiles and for high zoom rasters. Only raster images at zoom levels up to 10 are cached. Currently we can not deliver them fast enough otherwise.

Map updates

The database is updated from OSM using minutely diffs. We are usually about 3 to 5 minutes behind the OSM data, that’s just how long it takes the OSM servers to create the minutely diffs, push them out to their server and for our update job to download the data and to apply it to the database. It is unlikely we can improve on that much further. Spyglass shows the timestamp of the latest data it has in the bottom right corner. This timestamp is updated whenever new data is loaded, i.e. when you move the map or so.

Vector tiles are always generated on the fly from the current database, for higher zoom levels they contain all data, for medium zoom levels only “larger” objects are shown, i.e. long ways and larger areas. In small and medium zoom levels raster tiles are shown. They always contain all data. So for the medium zoom levels raster data in gray is overlayed with vector data in black (nodes and ways) or blue (relations). So you can see everything, but only click on the larger items.

Raster tiles in small zoom levels are only updated once per day, for zoom 0 to 7 this happens by taking the zoom level 8 tiles, and merging and rescaling them. I have spent quite some time on optimizing this. The first version happened in the database but only generated black-and-white tiles, the current version uses code written in Go which creates grayscale images which are much better than the black-and-white images. And it is much faster than the gdal tools I tried for this task. Gdal is a great tool, but, as an “all purpose tool”, it has to cope with all sorts of different data sources, projections etc. which makes it much slower than a specialized tool for a specific use case. It only takes a few minutes now to create the low zoom tiles from the zoom level 8 tiles. And they are not stored in the database any more but on disk which is easier and they are faster to use that way, too.

Rasters are still generated in the database from the data. That is, unfortunately, not as efficient as one might think. We don’t need to copy the data from the database into another process, and the cost of actually getting the data seems to be not that huge, but the rasterizing costs time. This is probably something that could be improved inside PostGIS, or maybe we have to get rid of this idea alltogether and move rendering outside the database. There is plenty of space to experiment and improve performance here.

Server

Originally I used pg_tileserv as server to create the vector tiles from the database on the fly. It could also be tricked into creating the raster tiles. But I also needed GeoJSON output and some other API endpoints. I experimented with pg_featureserv which did work, but having two servers with lots of specialized PL/pgSQL functions in the database plus an ever growing configuration for nginx (used as reverse proxy) became too complicated and error prone. So I decided to rewrite the server from scratch in Go. Turns out it is really easy to write robust and featureful HTTP servers in Go, it comes with everything you need; the only external library I am using is for accessing the database. And deployment is really easy: Just copy over one Go binary and restart the server, no extra configuration files or functions to update in the database etc.

Filters

Everything is done three times for nodes, ways, and relations. There are three sets of raster tiles, 3 sets of vector tiles. It is easy to switch those layers on and off in the UI. And then there is the key or tag filter. The vector tiles in higher zoom levels contain all the data, the filter is applied on the client, which is very fast. For raster tiles the filtering has to be done on the server which takes somewhat more time. Filtering is (silently) disabled on the small zoom levels, so you always see all data there. This isn’t great as a user experience, I’ll still have to figure out a way to make this transition more user friendly. Or, ideally, allow filtering on all zoom levels.

It is a lot of fun to zip around the map and look at far away places and how they are mapped. Try it out!. And if you have any problems or ideas, open an issue on Codeberg.

There has been a very interesting question on the OSM US Slack lately.

“Does anyone have a method to search through the OSM database for a building of a particular shape? I need assistance finding OSM buildings with this specific shape. They should be located in NJ, DE, northeastern MD, eastern PA, or southern NY.”

The question quickly exploded into a huge discussion. At the time of writing, there are already 71 replies.

Someone suggested :

“You could load OSM buildings into PostGIS and then use ST_HausdorffDistance to compare the geometries.”

From there, the discussion veered into how to solve that specific puzzle and find the exact OSM building in question.

One person added, “So the strategy is: create the shape of the building you want to search for, scale it to, say, fill a 100x100 m bounding box or something. Ask Postgres to, within a search-area bounding box, take each building and scale it to a 100x100 m bounding box, compute the Hausdorff distance with the scaled input shape, and return all OSM element IDs and their Hausdorff distances, sorted in ascending order.”

Another said, “What I’m currently doing is combining several shape exports into a single file with around 20,000 objects that have concavity. Concavity plus more than 10 nodes eliminates most buildings.”

At that point, instead of hunting that elusive specific OSM building, I became more interested in the generalized version of the problem.

So I added my two cents to the discussion:

“The generalized version of this problem would be : Can we represent a shape in some kind of data type that allows us to computationally check whether two objects have the same shape, regardless of rotation and scaling?

I haven’t studied the Hausdorff distance yet, but I’m wondering whether it can solve this problem, or if there’s a better alternative—Hu moments, Procrustes analysis, Fourier descriptors for contours…”

Someone replied :

“Hu moments are a good option. Elliptic Fourier Descriptors, Shape Context Histograms, Turning functions, etc. I’ve experimented with those four while trying to classify sports pitches more accurately. You can actually get pretty far with just compactness, convexity, and aspect ratio, thankfully.”

Do you have any other ideas on how to solve this problem?

New CNEFE Tool Revolutionizes Street Name Correction in OpenStreetMap Brazil

The community of Brazilian mappers has just gained a powerful ally to improve one of the most crucial and, at the same time, challenging data points in any map: street names. The CNEFE Verification System platform has been launched, accessible at https://cnefe.mapaslivre.com.br, a tool created by and for the OpenStreetMap (OSM) community in Brazil, aimed at validating and correcting address data using the latest information from the 2022 IBGE Census.

The project is an initiative of UMBRAOSM (Union of Brazilian OpenStreetMap Mappers) and was developed by experienced mappers Raphael de Assis, president of UMBRAOSM and member of the OpenStreetMap Foundation, and Anderson Toniazo, both active members of the OSM Brazil community. The tool arrives to solve a long-standing bottleneck in national mapping: the updating and verification of street names based on official sources. The Challenge of Street Names in Brazil

For those mapping in Brazil, one of the biggest challenges has always been the lack of a complete, accurate, and freely accessible street database. Through the Demographic Census, IBGE compiles the National Registry of Addresses for Statistical Purposes (CNEFE) . This registry is a vast list of addresses from across the country, containing street names, address types, neighborhoods, and, in many cases, geographic coordinates, especially in rural and non-residential areas.

Historically, the OSM community has used CNEFE data from previous censuses (such as 2010) to enrich the map. However, the process was complex, involving downloading text files (fixed format), cross-referencing them with census tract shapefiles, and extensive manual work to match the information with the streets already drawn on the map, in addition to correcting spelling differences.

With the recent publication of the CNEFE 2022 microdata by IBGE, the need for an efficient tool to integrate this new data into OSM became even more evident. CNEFE System: A Bridge Between Official Data and the Collaborative Map

It is in this context that the CNEFE Verification System emerges. The platform created by Raphael de Assis and Anderson Toniazo is not just a data viewer; it is a complete work tool, designed to optimize the collaborative verification and correction workflow.

The system’s intuitive interface allows mappers of all experience levels to:

Visualize CNEFE 2022 Data: The tool presents official address data from the most recent census clearly, overlaid on the map.

Compare with OpenStreetMap: The mapper can easily identify discrepancies between a street name recorded in CNEFE and the name currently present in OSM.

Correct and Include Names: When a street in OSM is unnamed (very common in less mapped areas) or has a different name than the IBGE registry, the tool facilitates the correction and inclusion of the correct name directly on the map.

Fill Gaps: In places where IBGE registered addresses, but the corresponding streets have not yet been drawn in OSM, the application highlights these areas, encouraging the complete mapping of road geometries and, subsequently, the addition of names.

The platform is already at version 1.0, updated on January 22, 2026, and features rich support material for the community. Mappers can access a step-by-step tutorial with images, watch demonstrative videos, and even download complete PDF tutorials for offline consultation, ensuring everyone can make the most of the tool. The Strength of the Community Behind the Tool

The development of the CNEFE System is a testament to the power and organization of the OSM Brazil community. UMBRAOSM, under the leadership of Raphael de Assis, has stood out for promoting initiatives that facilitate and professionalize collaborative mapping in the country. Projects like “Mapeia Crato” have already demonstrated the capacity of unity in training new mappers and carrying out large-scale tasks.

The partnership between Raphael and Anderson in developing this tool reinforces the community’s commitment to not only use open data but also to give back, creating ecosystems that improve the quality of geospatial information available to everyone. Their work directly aligns with broader discussions within the community, such as the matching of CNEFE 2022 variables with OSM tags, a fundamental step for any data import or validation process. A Future with More Accurate Maps

The availability of the CNEFE System marks a significant advance for Brazilian mapping. By facilitating access and comparison with official Census 2022 data, the tool not only speeds up the map update process but also increases the reliability of the OpenStreetMap database as a whole.

For the end-user, whether a driver using a navigation app, a delivery person, or a researcher, the result is more accurate maps, with correctly identified streets and addresses that are easier to locate. The CNEFE tool is, therefore, a key piece in Brazil’s open data infrastructure, built collaboratively by those who understand the subject best: the mapping community itself.

Visit https://cnefe.mapaslivre.com.br and start contributing to a more complete and correct map of Brazil.