Today I received an invitation to attend the bi-monthly OSM US Maintainers Working Group.

But due to timezone difficulties, I don’t think I’ll be able to attend it live.

The meeting agenda has been shared, mainly focusing on the topic of standards and interoperability. There are some interesting starter questions there, so I’m intrigued to answer those questions in an OSM diary instead, hoping that I’ll be able to join the discussion asynchronously.

So, here we go :

---

“What standards (geospatial file or data formats, metadata schemas, wire protocols, structured text formats, encodings, etc.) does your project depend on or interact with?”

I frequently use GeoJSON format in several of my projects.

“Are there any standards that you wish would be evolved/extended but aren’t actively maintained? Or implementations that aren’t fully compliant that you wish would be?”

GeoJSON fits pretty much all of my required use cases. My only concern right now is how to make GeoJSON files more compact. I haven’t researched much about this since there’s currently no urgent performance issue that needs to be handled, but I love tweaking my apps for performance.

“Are there standard formats or protocols that you would like to use, but aren’t well supported in your language/ecosystem?”

The General Transit Feed Specification.

I’ve been interested in this data format for a long time, but I still don’t know how to properly tinker with it. Last time I worked on this, I had to make my own Python implementation to read and navigate GTFS files. I don’t know what the current situation is right now. Maybe it’s already supported, maybe not.

“What are your thoughts on Overture’s OGC proposal?”

I already posted my thoughts in a certain Slack thread somewhere. Here’s the verbatim quote:

“Does an OGC standard become legally binding worldwide or something?

… See full entry

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 :

… See full entry

Starting in 2026, I slightly adjusted my daily routine, particularly around my weeklyOSM-related activity. Instead of passively consuming updates, I began actively scanning for news by lurking in several regional OSM online groups. Occasionally, genuinely newsworthy discussions emerge there.

One such case appeared today in the OpenStreetMap Braga (Portugal) Telegram group.

In the aftermath of Storm Kristin, which recently hit Portugal, multiple OSM-driven humanitarian initiatives surfaced. These efforts focused on mapping damage, identifying locations that require assistance, and highlighting places offering help.

At some point, the discussion shifted toward the need for a truly offline mapping application. Connectivity issues in affected areas appeared to render many OSM-based emergency platforms ineffective, simply because they still depend on an active internet connection.

This resonated with my own experience. I have built several “half-offline” OSM-based applications before. They are only partially offline because they store coordinate data locally in the user’s browser, while the application code itself and the OSM map tiles still require network access.

That led to a straightforward question: if we want a truly offline application, shouldn’t the map tiles themselves also be stored locally in the browser? Storing coordinate data is already trivial, but what about images? BLOBs? Is this feasible at scale?

While I was still thinking through these constraints, someone in the same Telegram group announced that an offline emergency platform had already been built. Naturally, I was curious and tested it by toggling my network connection on and off.

The result was clear: the application remained accessible offline.

… See full entry

This morning, when I woke up, I felt that something was different. The sky looked darker, the temperature felt colder, and the faint sound of drizzling rain outside carried a gloomy tone.

I immediately rushed to check the forum chat that morning, trying to scrape together information. What was going on out there?

07:17:55: “Heavy rain”
07:18:44: “Same here in Bogor”
07:19:39: “With a storm like this, how am I supposed to get to the office?”
07:39:11: “Anyone in North Jakarta who lives toward the east / near Bekasi. Is it storming there?”
07:40:20: “Yep. Storming. Starting to ease up a bit though.”
07:48:25: “Seems pretty widespread. Cikarang’s getting wind and rain too.”
07:50:04: “Still early morning but the rain is insanely heavy. What a Monday.”
07:55:41: “With rain this heavy, it’s best to just go back to sleep~”
08:00:26: “Heavy rainnn”
08:10:46: “The rain is so damn heavy.”
08:14:28: “Waiting for it to stop, but it’s just getting heavier.”
08:16:52: “This storm. No way I’m working. Just want to WFH.”

Heavy rain? A storm? How bad could it be? Here, the rain was only a light drizzle, but the darkness of the sky and the chill in the air felt very different. This wasn’t ordinary rain.

I kept reading the forum.

08:15:11: “Same in Central Jakarta, storm-level rain. Can’t work at all.”
08:29:58: “Force majeure, man. I ain’t leaving for work like this.”
08:37:55: “With rain this bad, offices should really normalize letting employees WFH, at least for sectors that don’t need physical presence."
08:40:00: “Stuck getting out of Tanah Abang. The rain’s way too heavy.”
08:45:47: “Early morning chaos in the airspace above CGK. Looks like no planes can land. Four domestic flights diverted to Lampung. Flight SQ950 had to do three go-arounds. This morning’s rain is insane.”

Huh?

So many planes couldn’t land at Soekarno-Hatta? How bad was the rain last night?

… See full entry

“From here, how do we get to Ragunan Zoo?”

Good question.

I paused. This wasn’t a matter of intuition; it was a routing problem.

I opened a navigation app, queried the destination, and switched the mode to public transport. The proposed solution was a multi-hop journey : take the blue commuter line to Manggarai, transfer to the red line toward Bogor, get off at Pasar Minggu, then continue with something called S15A.

S15A?

That identifier triggered a red flag. After a quick lookup, it turned out to be an angkot.

That immediately raised another question. Was there really no direct busway route to Ragunan? Not even a JakLingko alternative? Cost sensitivity was also a concern. There are plenty of public transportation modes in this city: MRT, LRT, Commuter Line, Transjakarta BRT, and Transjakarta non-BRT, but angkot and ride-hailing motorcycles are the two worst options, since they can end up being pricey due to the lack of government subsidization.

At that point, I decided to discard the initial navigation output entirely. Close the app. Start over with a more specialized tool.

I switched to the official Transjakarta application.

It refused to open and forced an update. Fine. Update first, then rerun the query.

Post-update, I defined the problem more explicitly. Assume the train leg was already completed. Starting point: Pasar Minggu Station. Destination: Ragunan. The goal was to find a replacement for the S15A angkot.

Search results came back clean. Instead of S15A, there was a JakLingko option: JAK47, Pasar Minggu–Ragunan. That was acceptable. Same endpoint, better integration.

Solution candidate number one locked in.

---

Then I expanded the scope. What if we removed the train entirely? What if the journey started directly from Bekasi using Transjakarta, via Vida to Cawang Sentral?

New query. New parameters. Starting point: Cawang Sentral. Destination: Ragunan.

… See full entry

Last weekend I traveled to the west coast of Java, specifically Anyer in Banten. The journey was done by train from Jakarta to Cilegon, followed by a local shared minivan taxi to Anyer.

Throughout the trip, I collected field observations using Sakumap. The result was a raw GeoJSON file containing coordinates and timestamps for each entry.

For observations I considered significant, I wrote a detailed report on the OSM Wiki. Less critical features such as restaurants, fuel stations, farms, and forest areas were added directly to OpenStreetMap by importing the Sakumap GeoJSON into iD Editor or JOSM, without additional documentation on the wiki, as the overhead did not seem justified.

… See full entry