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

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.

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

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.

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

Hello I’m a former Marine and an American who still believes in The Constitution and the words written in it!!! Stand up!!! Stand together!!

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 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

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

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.

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

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.

For a while, the “Dienst Mobilteit van Antwerpen” (Department of Mobility of the Province of Antwerp) wanted to have (libre) streetview imagery, especially of the Belgian “cycle highways” - a type of cycling network in Belgium.

Mapillary and Panoramax are - of course - a part of their solution.

But how to actually take the pictures? It requires someone travelling along all the cycle paths.

This is where the “groendienst” (the department of Parks + greenery) comes in. They are cycling along all the cyclepaths, to make an inventory of all the invasive species. A special cargo bike is equiped with a special camera to scan the greenery and to automatically detect those invasive species.

The Mobility Department then asked to also install a GoPro on this cargo bike. And just like that, for practically no extra cost, they have streetview imagery!

You can see the cargo bike (parked in their parking garage) here

Singapore has about 2,300 playgrounds in OSM (leisure=playground), but no easy way for a parent to answer the practical question: is this one any good for my kid, today?

So I built PlaySG (https://playsg.sg): a free MapLibre GL map of every playground in the country, refreshed weekly via Overpass. On top of the OSM base it layers AI-read photo tags (shade, equipment, age fit), Google names and ratings where they exist, live NEA weather and haze, the nearest MRT station, and first-party reviews from parents. No ads, no accounts.

A couple of things I learned along the way: tag coverage is sparser than you’d expect — only ~180 of the ~2,290 OSM playgrounds carry a name, and indoor/wheelchair tags are rarer still, which is exactly why the photo-reading layer earns its keep. On the bright side, the weekly Overpass diff regularly catches brand-new playgrounds within days of new estates opening, which still feels a little magical.

Every playground links back to its source object on osm.org, and the About page credits ODbL. Feedback from Singapore mappers is very welcome — especially wrongly-tagged playgrounds, which the app makes easy to spot (and then fix at the source).

Today marks exactly one year since I started making changes to the map of Korea using openstreetmap.

my projects: 제주시 원도심 * 영흥면 * 거북섬 * 제부도 * 대부동 * 영종도 and 자운대

During this time, I’ve met many talented people, participated in many projects that will benefit people for decades to come, and of course (how could I not?), I’ve also satisfied my ego with athletic achievements. Mapping is a great hobby for people like me who can never get enough of new data. Every day of mapping brings new knowledge, and with it, new emotions.

I’ve heard a lot of opinions this year. That mapping is about freedom. That mapping is about community. That mapping is about the environment in which a person lives. Perhaps all of this, and more, is completely true. But for me personally, mapping is about knowledge, data, and education. It’s like having a sweet tooth and finding a bottomless sea of ​​sugar. It’s like finding a beach where diamonds are scattered right under your feet.

… See full entry

this morning, i wanted to find an important manuscript in my archive for work purposes.

while digging through the archive, i found this thing.

… See full entry