🗺 NOVA FERRAMENTA CNEFE 2022 IBGE PARA O OPENSTREETMAP 🚀

A maior atualização da ferramenta de logradouros chegou!

O sistema que verifica nomes de logradouros a partir dos dados do CNEFE 2022 foi completamente reformulado com base no feedback da comunidade! 🔄 O QUE MUDOU? MÃO DUPLA!

Antes: Apenas corrigíamos o OSM com base no CNEFE

Agora: Compatibilização mútua entre as duas bases!

✅ Se o OSM estiver errado → Corrige no mapa (JOSM/iD) ✅ Se o CNEFE estiver desatualizado → Corrige na ferramenta

“Preparando o terreno para a futura importação em lote dos endereços!”

🎯 NOVIDADES IMPERDÍVEIS

🔐 Login via OSM - Autenticação obrigatória (adeus bots!) 📦 Edição em Lote - Resolva vários logradouros de uma vez (use com cautela!) 🔗 Integração Overpass-Turbo - Verifique fontes no OSM rapidamente 📋 Cópia Automática - Nome corrigido já vai pro Ctrl+V! 🏷 Alternador Via x Lugar - Para praças, vilas e casos especiais 📊 Histórico de Colaboração - Veja quem já ajudou na sua área

… See full entry

RETEX : Questions existentielles sur ma rencontre avec panoramax

à suivre peut-être :

• entrée de journal (à venir) : Cartographier mon village
• entrée de journal (à venir) : Simple model 3D dans OSM

Je rappelle que ces entrées de journal ne sont ni des pages de WIKI, ni des conseils d’expert … . Ce sont juste des comptes-rendus d’expérience vécue ou des questionnements en cours mis ici pour servir à toute personne intéressée.

A l’origine : mon trekking urbain recyclage

(voir entrée de journal trekking urbain)
Lorsqu’il est apparu, en juin 2025, que j’allais passer devant les 1600 (que je pensais alors être 284) points d’apport de mon territoire, un contributeur m’a demandé de penser à tous les photographier et de verser les photos dans Panoramax, ce que j’ai accepté aussitôt.

Et me voilà parti avec mon smartphone à la main pour photographier chaque point d’apport (en fait une photo par conteneur et une photo pour le point d’apport constitué par le groupe de conteneurs). J’ai aussi à l’occasion pris des photos de quelques points notables (notamment des oeuvres de street art croisées au bord des chemins).

Comme je répondais à une demande sans avoir vraiment réfléchi à l’objectif, je ne me suis posé que peu de questions. J’ai rapidement compris qu’il y avait plusieurs instances de Panoramax avec un répertoire commun (références coordonnées entre les instances) et ai choisi l’instance OpenStreetMap simplement parceque je répondais à une demande OSM et visais principalement à mettre l’attribut panoramax=xxxxx sur mes conteneurs.

Rapidement une question : pourquoi ces photos?

Au bout de 800 photos versées (j’ai peut-être l’esprit un peu lent), je me suis interrogé sur l’intérêt de ces versements. J’y voyais deux objectifs possibles :

… See full entry

Ajout du parcours de “Mâcon Disc Golf - Parcours P.A.P.A.” à Mâcon (71)

Par ici : osm.org/node/14041516470

… See full entry

Seit ein paar Wochen versuche ich, möglichst viele offene OSM-Notes um Dingolfing abzuarbeiten. Es macht mir echt Spaß. In meiner Freizeit mache ich seit letztem eigentlich nur zwei Sachen: mappen und Survey machen.

Wo ich angefangen habe, war in Dingolfing fast alles rot (von den Notes her). Jetzt ist die Hälfte (oder vielleicht sogar mehr als das) grün.

Mein Ziel danach ist es, einige Osmose-Fehler zu beheben.

More details – https://community.openstreetmap.org/t/should-diary-entries-move-to-community-openstreetmap-org/145754

Ho pubblicato su uMap una mappa interattiva che raccoglie i punti vendita delle principali catene di fast food presenti in Italia.

Al momento la mappa include:

• McDonald’s
• KFC
• Burger King
• Starbucks
• La Piadineria
• Roadhouse
• Alice Pizza
• Billy Tacos
• Old Wild West
• Five Guys

Tutti i dati sono stati raccolti direttamente dai siti ufficiali delle rispettive catene, con l’obiettivo di offrire una panoramica il più possibile completa e aggiornata della loro distribuzione sul territorio italiano.

Link alla mappa: https://umap.openstreetmap.fr/it/map/fast-food-chains-in-italy_1437687

I have been mapping on OpenStreetMap for a little over 11 months now. However, OpenStreetMap is not where my love for mapping started. 7 months beforehand, I started editing Google Maps. Every time I had a minute of free time, whether at my computer or on my phone while going to school, I would trace roads all around the world. I completely stopped doing anything else for fun other than fixing and creating roads.

However, this craze of mine ended on August 12th, 2025. I found out that more than 50% of my edits were being rejected by Google when I knew that all of them were OBJECTIVELY correct. I decided that I was done with Google Maps, but I needed something new to fill the hole that mapping had in my heart. That’s when I discovered OpenStreetMap 15 minutes later. I knew I had heard that name somewhere, so I decided to check it out.

Before I even completed the tutorial, I was hooked. While before I could only map walking paths, now I could map literally anything I want. Even the concept of mapping buildings was something I had to get adjusted to due to how small the number of things I could map on Google Maps was. I spent the rest of my day figuring out the mapping capabilities of the iD editor. The next day, I spent the entire day mapping and seeing what others had already mapped (spoiler alert: a lot).

… See full entry

قانون برای ایجاد کسب و کار در ایران: 1. تگ phone برای تلفن ثابت است و تگ mobile برای تلفن همراه - هرگز از تگ phone برای تلفن همراه استفاده ننمایید 2. تگ website برای دامنه کسب و کارشان است (در صورتی که دامنه ثبت شده باشد) و تگ contact:instagram برای آدرس صفحه (پیج) اینستاگرام. - هرگز ار تگ website برای صفحه اینستاگرام استفاده ننمایید 3. تگ payment:shetab_cards برای کارت‌های ایرانی است و هرگز از تگ‌های payment:visa، payment:mastercard و… استفاده ننمایید چون ویزا، مسترکارت و… در ایران نیستند. مگر آنکه آن مغازه، آن‌گونه کارت‌ها را بپذیرد تگ شبکه شاپرک هم shetab cards است

In late-2025, we received a grant through NGI0 Commons Fund, a fund established by NLnet with financial support from the European Commission’s Next Generation Internet program to integrate vector tiles in uMap. This is a huge amount of work considering that a few non-trivial steps are required prior to be able to achieve that goal!

What “vector tiles support” means for uMap? At least, being able to render tiles on the Mapbox vector-tiles format (the de-facto standard), but, and that’s the interesting and hardest part, ideally to be able to customize those tiles: what if I can add a vector tiles style, but remove the buildings or change the road colors, to better fit the purpose of my map?

uMap used to be 100% coupled with Leaflet. In fact, it was initially designed as a storage for Leaflet — the first version of uMap was just a wrapper around Laflet.Storage plugin and django-leaflet-storage backend (well, the really first version was called django-chickpea, but that’s archaeology…).

So, our first need is to decouple from Leaflet, and clearly separate the rendering and the data. This is a work we have already started in the last two years but it was still unfinished (is a software ever finished is left as an exercise for the reader). Then, we want to take advantage of ES6 modules to only load the required JS files and speed up maps’ rendering (especially for read only access!). Finally, we currently rely on a lot of Leaflet plugins which are mostly either outdated and/or unmaintained that we need to port or adapt to the new chosen ecosystem.

Given that context, we are ahead of a long run BUT we already started at a good pace! Follow current PRs if you are curious. Now you may wonder why we choose OpenLayers as a target goal for vector tiles rendering over existing alternatives. Here are some of the reasons:

… See full entry

A quick update on where things stand after the first half of the coding period.

In my first post I mentioned three goals for the summer. The first one, adding a Valhalla-powered routing endpoint that genuinely avoids closed roads, is now done.

What I built

The platform already had road closure data in the database. What it was missing was any connection between that data and actual routing. The frontend was calling valhalla1.openstreetmap.de directly, with no awareness of the closures sitting in our own database.

I set up a self-hosted Valhalla instance (3.5.1) running in the project’s Docker stack, loaded with Switzerland OSM data. Then I built a backend endpoint, POST /api/v1/routing/closure-aware, that sits in front of Valhalla and does the work the frontend couldn’t do on its own:

1. Fetches currently-active closures from the database that affect the requested transport mode (car, bicycle, or pedestrian)
2. Buffers each closure geometry into an avoidance polygon. LineStrings get a 10m buffer, Points get 15m, Polygons are used as-is. The buffering uses per-centroid UTM reprojection so the radii are true metres anywhere
3. Sends those polygons to Valhalla as exclude_polygons so the route detours around them
4. Returns the trip along with a count of how many closures were excluded

The frontend routing page now calls this endpoint instead of Valhalla directly, so closure avoidance happens server-side automatically.

Coverage

The self-hosted Valhalla currently covers Switzerland only. For routes outside Switzerland the frontend falls back to the public Valhalla instance without closure avoidance, which is fine for now since the platform is Swiss-focused.

Next up is the sidecar service that feeds active closures into Valhalla’s traffic tile system, the second item from my original list. More on that soon.

The code is on GitHub if you want to follow along.

Bonjour,

J’ai récemment découvert la notion de Bassin de Vie (je vous laisse lire la définition vous-même, wikipédia expliquera mieux que moi), et je me suis dit que les communes centres de ses bassins de vie pourrait être tagger comme “petite ville”, afin d’être au plus proche des réalités locales. Cependant, les données varient entre 2012 et 2022, ainsi je propose de faire une estimation large, et d’inclure les communes centres de ces deux set de données. Disponible sur le site de l’INSEE.

Merci, bonne journée

鹿児島市の建物数集計(2026年7月17日時点)

• ちょっと気が早いが、中間報告。サボってないよってことで

検証用データ

• 基準建物数
  • 国土地理院ベクトルタイル(PBF)
    • 2026年7月1日時点
• 比較対象数(OSM)
  • Geofabrik(PBF)
    • 2026年7月17日時点
• 抽出エリア(行政界)
  • e-statより国勢調査(2020年小地域（町丁・字等）)
• 処理は前回どおり

集計結果

地域	GSI	OSM (4/24)	OSM (7/17)	増	進捗率	残り
全域	263,088	135,984	181,057	45,073	68.8%	82,031
中央地域	88,190	63,323	76,609	13,286	86.9%	11,581
谷山地域	69,752	34,740	45,704	10,964	65.5%	24,048
伊敷地域	27,596	7,790	18,597	10,807	67.4%	8,999
吉野地域	27,758	12,638	17,359	4,721	62.5%	10,399
桜島地域	6,868	4,960	6,883	1,923	100.2%	-15
吉田地域	11,164	5,413	6,610	1,197	59.2%	4,554
喜入地域	10,994	2,484	3,849	1,365	35.0%	7,145
松元地域	11,470	2,958	3,483	525	30.4%	7,987
郡山地域	9,296	1,678	1,963	285	21.1%	7,333

感想

進捗

• 4月集計から約45,000棟増加し、網羅率も51.9%⇒68.8%まで向上した
  • 主に新興住宅地と現地調査で通った道路周辺をできるだけ毎日少しずつ建物を追加した
  • 桜島地域は基準値に到達したので、ひとまず完了とした
  • 中央地域は現在作業中の「田上台」周辺で完了しそう
  • 谷山地域は「清和」「坂之上」「錦江台」の住宅地がまだ残っている
  • 伊敷地域も順調に進んでいる一方、丁目単位で未着手の区域が点在している
    • 作業場所を頻繁に切り替えたため、丁目単位で未着手の区域が点在する結果となった
      • 今後はもう少し計画的に進めたい
  • 郊外地域はまだほとんど手付かず

モチベーション

… See full entry

Please refer my March 2025 diary entry as this is changes only.

• Changed the voice recording notes method to a dedicated microphone nearer my face. I launch a script at the same time I start the side cameras. It still saves as date/time stamped 1 minute length files.

• Use a dedicated 2nd WiFi device on the laptop for direct connection (not using in van WAP) to the 225deg side facing camera. This increases the max framerate slightly. The 270deg side camera is still USB connected.

• Procured a cheap 2K dashcam and mounted it rear window. Actually has a GPS position reporting fault, but the clock is okay. Do a lot of local processing to geotag against the UBLOX GPS unit to give 1FPS above 45kph and 3FPS below. Very handy for capturing the back side of speed signs by either swapping views locally or seeing the signs recognised on Mapillary.

• The WiFi/cell router now has two antennas connected (MIMO) which helps the upload rate rate and low signal area performance. Now upload 15-40GBytes for each drive day.

• One of the 20 year old Toshiba laptops had a temp sensor fail such that the cooling fans wouldn’t start. Upgraded both to 10 year old HP Probooks. These reduce processing time approx in half. The extra dashcam included. Still running Debian Linux.

• No longer beacon APRS.

• GPS nav unit now has giveway and stop sign POI’d displayed, so I can add these to the voice notes. I continue to create other special POI’s plus modify the mkgmap process for better end use.

Currently near Injune Qld about to sit still for a while.

Cheers Bob

双击放点，再点，双击结束 * 地震级的编辑体验 欢迎前往 map.osm.asia 体验

BetteriD 和 map.osm.asia

今天想认真介绍一下 BetteriD，它是 map.osm.asia 默认搭载的编辑器。

BetteriD 是一个基于 OpenStreetMap iD 的改进版编辑器。它的目标不是简单地“换个皮肤”，而是尽可能补齐 iD 长期以来一些影响编辑体验的细节。

我们希望保留 iD 轻量、直接、易上手的特点，同时逐步补充正式版缺失的偏好设置、编辑细节、移动端体验、快捷键兼容，以及一些更加现代化的辅助功能。

简单来说，它是一个更适合长期使用、更贴近实际编辑习惯的 OSM 编辑器分支。

本次更新

这次更新的重点只有一个：让编辑更顺手。

明确区分官方与第三方

首先，编辑器启动时会明确提示当前并非 OpenStreetMap 官方站点。

这样做不是为了制造距离感，而是避免用户误认为自己正在使用官方服务。BetteriD 虽然努力提升编辑体验，但它依然是一个独立项目，不应该与官方站点混淆。

基础体验改进

这一版本修复和优化了不少长期影响使用体验的问题，例如：

• 翻译继承源从开发版调整为正式版，避免不稳定内容进入翻译链。
• Bug 反馈入口不再直接指向本项目。

• 修复和优化多个已知问题，例如：

  • 缩放后元素大小偶尔异常；
  • 对象卡住但地图仍可移动；
  • 缩放与平移状态不同步等。

更符合编辑习惯

我也调整了不少快捷键和地图操作，希望更符合老编辑者的使用习惯。

包括：

• 兼容部分 JOSM 常用快捷键（在不冲突的前提下）。
• 支持按住右键拖动平移地图。
• 持续优化整体交互逻辑。

更好的移动端体验

移动端一直是 iD 的短板，因此 BetteriD 做了一些针对性的优化，例如：

• 减少菜单层级；
• 双击进入绘制；
• 再次双击结束绘制；
• 长按添加节点。

希望让手机编辑不再那么繁琐。

AI 辅助功能

AI 功能目前仍在持续完善，但设计目标始终是用户体验优先。

当某个模型或接口失败时，并不会直接把错误展示给用户，而是会按照预设优先级自动切换备用方案，实现尽可能平滑的回退。

目前涉及的能力包括：

• 网络搜索；
• 标签建议；
• 文本生成等。

同时，偏好设置支持用户自行配置模型优先级，而不是固定使用某一个模型。

正在开发中的实验功能

除了现有功能外，还有一些实验性功能正在推进。

包括：

• 支持导入本地照片作为辅助底图，不上传、不审核、不参与 POI 识别，仅用于本地编辑参考。
• 上传图片后可调用公开接口，在需要时进行图片审核和 POI 识别，与本地照片模式完全独立。
• 根据自然语言描述，由 AI 自动生成 OSM 标签建议。
• 支持叠加两种底图，并可自由调整透明度进行对照。
• 室内编辑增强：选中当前楼层后，自动弱化其它楼层及无关图层。
• WASD 地图移动，默认采用步行模式，并尝试实现更加流畅的飞行模式。

更完善的偏好设置

BetteriD 也在逐步补齐 iD 正式版已有以及缺失的偏好设置。

目前包括：

• 翻译语言数量；
• 智能拆分依据；
• 吸附范围；
• 默认隐藏行政区边界；
• 实验功能总开关；
• 更多可配置选项。

未来仍会继续完善，让更多功能交给用户自由选择，而不是固定写死。

最后

我最喜欢这次更新的一点，并不是增加了多少功能，而是 BetteriD 正在慢慢变成一个真正适合长期使用的工具。

它还不完美，也还有很多地方需要继续打磨，但方向一直没有改变：

让 OpenStreetMap 编辑少一点阻力，多一点顺手。

GitHub：

https://github.com/koharachan/BetteriD/

ps：小声告诉你，实验功能其实已经可以用了哦

Bugün Başladım Hasan Doğan Civarını Yaptım

I hate route relations. They make editing roads a nightmare, and they’re likely to be out of date. All people need is the list of stops, not the actual roads.

osm的小伙伴们大家好，今天我无意中发现了osm可以写日记然后放在自己的首页中。有的小伙伴分析地区编辑完完整度，有的教大家正确使用地图标签。虽然我注册有三年多了但是论辈分还是个小老弟😂，那我就写写我比较擅长的东西，欸要不我就写写有关家乡的一些事好了哈

---

关于康居路

枞阳县枞阳镇旗山社区邻近枞阳县人民医院、银塘花苑与银塘星城这三个区域中间有一条三级道路，道路有花坛阻拦，两条单行道形式，双向四车道（高峰期两车道因为两边可以停车）

这条道路的命名其实非常迷，枞阳县地图与天地图将其命名为健康路，而枞阳县ZY-02银塘行政区规划文件与地名信息系统将其命名为康居路（商业地图通常采用后者）。这条路到底叫康居路还是健康路？

其实我住的地方离这条路不远，所以经常在傍晚散步时走这条路。根据我的见解以及查阅对应文件的思路，这条路现阶段应该还是命名为康居路为好，至少26年8月之前还是得叫它康居路

1. 根据路灯管理局的路灯标签判断

26年初，县里开展《城市生命线》安全设备部署工作，在大街小巷安装了监测设备，同时县里也提及同日设立路灯管理所。随即4月份县里的每个路灯都贴上了标签，其中这条路的路灯被贴上康居路标签。这项工作是领先于枞阳县地图的制作的，可以认定当前这条道路仍为康居路

2. 根据枞阳县ZY-02银塘行政区规划文件中康居小区存在与否判断

在枞阳县地图中，康居路并未消失而是跑到了旗山小学与中海山水城的区域中间，而它的命名依据是因为附近有个小区名为康居山庄。但是无论是在枞阳县ZY-02银塘行政区规划文件中，还是在旗山社区服务站点地图中，这个不是小区，是银塘村的回迁房，经简单查阅县政府公开文档初步确认区域名为银塘安置地。真正现存的“康居山庄”在妇幼保健院旁边，不过叫康居家园。当然不排除小区未来改名的情况

其次那条路虽然在路灯管理所的标签、附近停车场名称以及路牌中没有给出详细名称，但是在枞阳县ZY-02银塘行政区规划文件中，这条路被命名为安置地路。鉴于规划文件的审图号较枞阳县地图较新，该未分级道路我建议命名为安置地路，而保留原先的康居路命名位置

---

为啥要写这条路

上次有个过于热心的小伙伴将康居路所在道路标为健康路（与此同时他还把旗山路标为莲城路，而莲城路是天地图的一处过时标记，我有时间在下一次日记里说），希望我的笔记能在我没时间贡献枞阳的时候，给其他人一些有理可循的参考（与此同时我也会夹带一些私货介绍枞阳有什么有意思的地方，比如枞阳中学占据的地方曾经有个自然村叫答咀村，这个村的来历可神奇了，另开一个新坑），望大家多多关照👋

Today, someone mentioned to me that there’s an ongoing “reform” of a certain local tagging scheme.

At first, I really, really, really, really, really didn’t want to get involved at all.

But in the end, I decided to give it a try and skim the proposal anyway.

---

After that, I wanted to present an argument.

To support that argument, I wanted to introduce this tool that I made several weeks ago.

But then I realized that I probably never made a blog post announcing it at all.

Weird. Usually, I always make a blog post whenever I finish an app.

After double-checking everything, I think it’s safe to say that I never made a blog post about this app.

Alright. Here we go : https://altilunium.github.io/terjangkau/

… See full entry

A quick update on where things stand after the first half of the coding period.

In my first post I mentioned three goals for the summer. The first one, adding a Valhalla-powered routing endpoint that genuinely avoids closed roads, is now done.

What I built

The platform already had road closure data in the database. What it was missing was any connection between that data and actual routing. The frontend was calling valhalla1.openstreetmap.de directly, with no awareness of the closures sitting in our own database.

I set up a self-hosted Valhalla instance (3.5.1) running in the project’s Docker stack, loaded with Switzerland OSM data. Then I built a backend endpoint, POST /api/v1/routing/closure-aware, that sits in front of Valhalla and does the work the frontend couldn’t do on its own:

1. Fetches currently-active closures from the database that affect the requested transport mode (car, bicycle, or pedestrian)
2. Buffers each closure geometry into an avoidance polygon. LineStrings get a 10m buffer, Points get 15m, Polygons are used as-is. The buffering uses per-centroid UTM reprojection so the radii are true metres anywhere
3. Sends those polygons to Valhalla as exclude_polygons so the route detours around them
4. Returns the trip along with a count of how many closures were excluded

The frontend routing page now calls this endpoint instead of Valhalla directly, so closure avoidance happens server-side automatically.

Coverage

The self-hosted Valhalla currently covers Switzerland only. For routes outside Switzerland the frontend falls back to the public Valhalla instance without closure avoidance, which is fine for now since the platform is Swiss-focused.

Tests

308 tests passing, including integration tests for all three transport modes and a version contract test that checks the Valhalla image is pinned to 3.5.1.

… See full entry