OpenStreetMap logo OpenStreetMap

Users' Diaries

Recent diary entries

鹿児島市の建物数集計(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

Location: 桜島横山町, 鹿児島市, 鹿児島県, 892-8677, 日本
Posted by bob3bob3 on 18 July 2026 in English.

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

BetteriD 和 map.osm.aisa

今天想认真介绍一下 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:小声告诉你,实验功能其实已经可以用了哦

Location: 风度北社区, 风采街道, 东河村, 韶关市, 浈江区, 韶关市, 广东省, 512002, 中国

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


关于康居路

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

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

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

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

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

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

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

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


为啥要写这条路

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

Location: 殷家老屋, 枞阳县, 枞阳镇, 枞阳县, 铜陵市, 安徽省, 246700, 中国
Posted by rphyrin on 15 July 2026 in English.

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

Location: Kamara, 1st District of Thessaloniki, Thessaloniki Municipal Unit, Municipality of Thessaloniki, Thessaloniki Regional Unit, Central Macedonia, Macedonia and Thrace, Greece

🚀 Conheça a nova plataforma MAPAFEST! 🗺️

Discover the new MAPAFEST platform!

🚀 Conheça a nova plataforma MAPAFEST! 🗺️

O MAPAFEST é uma plataforma de gincanas e torneios de mapeamento colaborativo utilizando o OpenStreetMap (OSM). Agora com uma interface totalmente renovada e novos recursos para a comunidade!

✅ O que você encontra no MAPAFEST

🔐 Login integrado com sua conta do OpenStreetMap

🏆 Criação de gincanas e torneios

👥 Competições entre participantes e equipes

📊 Ranking em tempo real para acompanhar sua pontuação

🗺️ Lista de tarefas para mapear diretamente no OpenStreetMap

🌎 Contribua para melhorar os mapas livres do Brasil e do mundo enquanto participa de desafios e evolui no ranking.

🔗 Acesse agora

🌍 Plataforma: https://mapafest.mapaslivre.com.br/

📚 Documentação: https://mapafest.mapaslivre.com.br/v.1/doc/

See full entry

Location: Gabiroba, São Domingos, Goiás, Região Centro-Oeste, Brasil

Leia em português

IVIDES DATA™ hosts the fifth session of 2026 OSM Workshop and launches an ebook on creating web maps with uMap

 

front_cover Front cover of the ebook A short guide to create web maps with uMap. Source of image and map data (c) 2026 OpenStreetMap contributors, uMap, and authors.

 

PREVIEW OR DOWNLOAD EBOOK (7.8 MB)

The preview and download may take a few seconds. Be patient, please.

 

Resources for creating web maps with uMap were presented during the fifth session (in portuguese): project creation and configuration, creation of static and dynamic layers, label customization, clustering and heatmaps. This event is part of the 2026 OSM Workshop Series (translation), organized by IVIDES DATA™ in partnership with the Institute of Geosciences at State University of Campinas - Unicamp (São Paulo, Brazil).

 

The files used in the fifth session can be found in the VIDEO DESCRIPTION

 

All content is available on the LEARNING PORTAL.

See full entry

Location: Recreio dos Bandeirantes, Rio de Janeiro, Southeast Region, Brazil

Read in English

IVIDES DATA® realiza a quinta sessão do Ciclo de Oficinas OSM 2026 e lança e-book sobre a criação de mapas na Web com uMap

 

front_cover Capa do e-book Mini guia de criação de mapas web com uMap. Fonte da imagem e dos dados do mapa: colaboradores do OpenStreetMap, uMap e autores.

 

VISUALIZAR OU REALIZAR O DOWNLOAD DO E-BOOK (7,8 MB)

A pré-visualização e o download podem demorar alguns segundos. Por favor, seja paciente.

 

Durante a quinta sessão, foram apresentados os principais recursos para a criação de mapas web com uMap: criação e configuração de projetos, criação de camadas estáticas e dinâmicas, personalização de rótulos, agrupamento (clustering) e mapas de calor (heatmaps). Este evento faz parte do Ciclo de Oficinas OSM 2026, organizado pela IVIDES DATA®, em parceria com o Instituto de Geociências da Universidade Estadual de Campinas - Unicamp (São Paulo, Brasil).

 

Os arquivos utilizados na quinta sessão podem ser encontrados na DESCRIÇÃO DO VÍDEO

 

See full entry

Location: Recreio dos Bandeirantes, Rio de Janeiro, Região Sudeste, Brasil
Posted by _PG_ on 13 July 2026 in English. Last updated on 14 July 2026.

It is a very rare moment, when somebody made a new JOSM tool, that must become one of main tools in you palette, like Building Tools or RelToolBox.

Meet Fillet Tools plugin. It will completely replace Fastdraw and partially replace Improve Way.

Silent let’s play demonstration on youtube: https://www.youtube.com/watch?v=agyY25jVeGM

OSM forum thread

Some important notes for newcomers of this tool:

1) Main buttons for this plugin: Shift-Enter-Alt.

  • Enter = finalize drawing (press it instead of last click if you connect end of line to the other way).

  • Shift + mouse roller = undo/redo drawed points

  • Alt = disable way justification mode. (!)

2) Do not make self overlapping of drawed line. If you press Enter during drawed line overlapping - drawed line totally dissappears instead become new way object on the map. This dissappearing may cause big done work loosing. (!) If you made overlapping, unroll it back using Shift + mouse roller. Overlapped line is gray, not overlapped line is red.

3) If you start and finish new line on the other existing way, FilletTools works in “Part of way redraw mode” (existing lines justification mode). In this mode on pressing Enter all existing way part between start and finish points will be deleted and changed by new drawed line. To skip this mode (for example if you add new multipolygone to the existing one, like scrub to forest), you must press Alt button once at any time during drawing new line. (!)

4) Using mouse roller without pressing Shift zooms your map view. Also, during new line drawing anytime you can use “Download map data in current view” button, so you can draw this line even outside of downloaded area.

An inadvertent typo recently led me to a slightly alarming discovery. Omitting the “r” from www.openstreetmap.org took me to a website that definitely wasn’t OSM, and prompted me to download something quite suspicious-looking. Thankfully I have my browser set to “paranoid” mode so things went no further, but it still felt like a near miss.

Apologies if I’m re-alerting folks to a known issue (a perfunctory web search didn’t turn up anyone else flagging this), and I’m not expert enough to know if there’s any legal and effective way to stop the impostor, but hopefully this is at least a helpful reminder to type carefully and trust your gut if anything smells phishy :)

Hello OSM community!

I’m excited to share a project I’ve been working on to map, analyze, and improve the data quality of places of worship across Saudi Arabia.

The website is live here: Saudi Places of Worship Map

Location: Al Futah, Riyadh, Riyadh governorate, Riyadh Region, 12613, Saudi Arabia
Posted by bluestarfish on 12 July 2026 in English.

One hot July evening ten years ago, I found my way to a bar somewhere near the Barbican in London and descended down the stairs into the basement space for the MapSwipe launch party. At the door I was handed my name sticker and asked to fill in the number of square kilometres I had already swiped on the app. I duly filled in my 597 sq km and joined the party.

sticker from the launch party

MapSwipe is an open-source mobile app where you swipe through satellite imagery and help identify features. The app was created as part of the Missing Maps project to help solve a problem we had in the early days. Mappers like myself would be asked to map an area to help a humanitarian project but we would open task after task with very little in it to actually map. So, the simple, but genius, idea behind MapSwipe is what if volunteers could do a first pass through the area and pick out the features that need to be mapped; then this smaller area could be presented to mappers to trace the data and add it to OpenStreetMap.

See full entry

Midterm is here, so this is a proper writeup of what’s landed so far, how the pieces fit together, and what the second half looks like. If you just want the code: everything described here merged in #4106.

Quick context for new readers: Nominatim identifies every place with a single class/type pair derived from OSM tags. An object tagged both tourism=hotel and amenity=restaurant becomes two rows in the database. Admin boundaries need admin_level special-casing everywhere. And there’s no way to express “wheelchair accessible cafe” at all. This project adds a proper category system to fix that at the database level.

Here’s the state of things at the halfway mark.

the data model: ltree[]

Categories are stored as an ltree[] column on place and placex, indexed with GiST. Each category is a dot-separated hierarchical path:

{osm.amenity.restaurant, osm.tourism.hotel}

I benchmarked this against TEXT[] with GIN during community bonding on a full planet import (~3 days to set up, worth it). The TEXT[] approach is what Photon effectively does at the OpenSearch level: pre-expand every prefix at index time (osm.amenity.restaurant also stores osm.amenity) and match with array overlap. It works, but you pay storage for every prefix of every category on every row, and the expansion logic lives in application code.

ltree understands hierarchy natively:


-- all amenities: restaurants, cafes, bars, everything below
WHERE categories @> 'osm.amenity'::ltree

-- exact match
WHERE 'osm.amenity.restaurant'::ltree = ANY(categories)

-- multi-value alternation (waterway checks)
WHERE categories ~ 'osm.waterway.river|stream|canal|drain|ditch'::lquery

Less storage, less code, and the query planner gets a real index to work with.

See full entry

Location: Action Area III, New Town, Kolkata Metropolitan Area, Rajarhat, North 24 Parganas, West Bengal, 700156, India

While field-testing an app I’m building for walking Public Rights of Way (MOROW), I found a real one. Chippenham parish path CHIP108, a legally recorded Byway Open to All Traffic, was mapped in OSM with highway=bridleway, ref=CHIP108, and a free-text note describing its BOAT status, but no designation= and no prow_ref=. Those are the two tags any PRoW-aware tool actually reads, so the path was rendering as an ordinary, unremarkable line. I fixed that one way directly (changeset 185555601), but the obvious next question was whether the same mistake, recording a council’s path reference under the generic ref= tag instead of prow_ref=, is a one-off or systematic.

Before building anything to find out, I went looking for prior art, and found it. Robert Whittaker’s UK PRoW toolkit (https://osm.mathmos.net/prow/) already does this properly, county by county, comparing OSM against official Definitive Map data and generating per-parish tagging-error reports with real way IDs ready to work through. For Wiltshire alone: 8,354 recorded rights of way, only 58% carrying designation=, only 24% carrying prow_ref=. That’s roughly 4,450 km of Wiltshire’s legal PRoW network without a prow_ref tag, a scale question the tool had already answered, far beyond anything I’d have worked out from scratch.

CHIP108 itself doesn’t appear on either of Wiltshire’s error lists, most likely because the detection starts from ways already carrying some PRoW tag and checks the other; CHIP108 had neither. I’ve asked on Robert’s forum thread (https://community.openstreetmap.org/t/roberts-openstreetmap- stuff-osm-mathmos-net/112981) whether that’s a known gap or something worth extending for.

Testing the fix workflow

See full entry

Like much of the web, OSM has been struggling with bots downloading rendered maps, in our case declining to use our planet dumps to get what they want.

I therefore make a suggestion: give suspected scrapers a poisoned version of the map, for instance it could have scrambled POIs, or perhaps roads named after villains. We can then point out the source of the resulting contamination as it goes public.