At KotobaMedia, we provide custom map services, and one part of that work is the basemap tiles our customers build on top of. Our main basemap today is a regularly updated, general-purpose map of Japan built on OpenStreetMap. We also tune it for Japanese use: we fold in official open data where it improves the result, make styling and priority adjustments, and apply the Japanese stance to disputed administrative boundaries where they differ from OpenStreetMap’s.
I wanted to write this post to share an overview of the process we have set up. This is not a hand-built map export that gets replaced whenever an update is needed. Instead, the pipeline refreshes source data, builds a new tileset, and publishes it in a controlled way. That process is what keeps the map current without turning each release into an ad hoc manual job.
A Pinned Build Environment
Before any scheduled build runs, the basemap logic is packaged into a versioned runner image together with the supporting assets it needs. The image is tested before being promoted to production. It also preloads the mostly static side data the build depends on, so the scheduled job can focus on refreshing Japan and generating tiles. In practice, this means the map-building logic is pinned to an intentional revision instead of changing invisibly underneath users.
Refreshing Japan Incrementally
From there, the regular build cycle starts by refreshing the OpenStreetMap extract used for Japan. Rather than downloading everything from scratch every time, the pipeline keeps a persisted extract, updates it with the latest changes, and clips it back to our Japan coverage boundary. That keeps the pipeline faster and more efficient while still letting us follow ongoing OpenStreetMap edits closely. The map currently refreshes weekly, and each update takes about 15 minutes end-to-end.
Building a Japan-Focused Tileset
Once that refreshed extract is ready, I pass it into our Planetiler-based build, built on top of the excellent Protomaps basemap work. OpenStreetMap is still the core source, but it is not the only one. Supporting datasets for coastlines, landcover, boundaries, and Japan-specific railway and transport context help keep the map clean and consistent, while the latest OpenStreetMap detail gives it up-to-date local data. This balance matters to me: I want the map to feel accurate locally and easy to use.
Publishing in Two Steps
When the build finishes, it produces a new PMTiles archive. The release goes to a dated, immutable location first, and only after that succeeds do I switch the live service to the new version. I prefer that pattern to replacing a live file in place. Users are never sent to a partially uploaded artifact, and older releases can remain available for rollback if needed.
Operationally, the tiles are maintained through a scheduled workflow, with additional on-demand builds when needed, rather than through ad hoc updates. The pipeline layer handles data refresh, execution, and publishing, while the underlying basemap repository defines how the map itself is assembled. That separation matters to me because the stability of the generated tiles should not depend on the mechanics of the pipeline itself.
If you use our tiles, I want you to know they come from a regular process, from pinned inputs, and from explicit release steps designed for reliability.
Thank you for reading. If you want to see how to use the KotobaMedia basemaps, take a look at the examples, and please contact us if you have any questions about building map-based solutions.