Planetary-scale answers, unlocked.
A Hands-On Guide for Working with Large-Scale Spatial Data. Learn more.
Authors
The other day, a customer dropped a question in our inbox that made us pause: "Hey, can we use PMTiles with Esri’s JavaScript API?"
Our first thought? Honestly, probably not. A quick scan of the ArcGIS Maps SDK for JavaScript documentation didn’t show any native support for the PMTiles format. It seemed like a technical dead end.
But "probably not" isn’t really our style. We love a good challenge, so we rolled up our sleeves, fired up our code editors, and started experimenting. And you know what? It is possible. With a clever little workaround, you can get the slick, serverless power of PMTiles lighting up your Esri maps.
This post is the story of how we cracked it—and how you can, too.
To understand the workaround we used with the Esri Javascript API, it helps to first appreciate the core problem PMTiles was built to solve: managing millions of tiny map files in cloud storage. Uploading and synchronizing a massive directory of individual tiles is slow and incredibly difficult to manage.
PMTiles elegantly solves that headache by consolidating everything into a single, cloud-optimized file.
Here’s how it works: a browser first reads the small header of the PMTiles file. This header acts as an internal directory, telling the browser the exact byte-range location for every tile inside the larger file. From then on, the browser uses efficient HTTP Range Requests to ask the cloud storage, "Hey, give me the tile located at position X, Y, and Z."
The result is a truly serverless format. You get the simplicity of managing a single file with the power to serve it directly from any object storage, drastically simplifying deployment and lowering hosting costs.
So, how do you get your own data into this powerful format? We believe that part should be simple, too. We built our own PMTiles generator to transform massive geographic datasets into a web-ready file with just three lines of code.
Our generator uses a distributed architecture to process your data in parallel for maximum speed, even on small hardware. As a quick test, we converted the entire TIGER railroad dataset—all 112,000 line-strings. The result?
This makes generating large-scale, web-ready PMTiles not just possible, but incredibly cheap and fast.
So, if PMTiles is so great, what’s the catch? The hiccup comes from how Esri’s VectorTileLayer expects to find its data.
VectorTileLayer
Out of the box, it’s looking for a classic tile server URL structure, something like .../Z/X/Y (zoom level, column, row). PMTiles, with its single-file, range-request approach, doesn’t speak that language. It’s a classic case of a mature technology that hasn’t yet caught up with the efficiencies of modern formats.
.../Z/X/Y
To get them to talk to each other, we need to build a small translator. In this case, it’s a lightweight service that sits in the middle, fetches data from the PMTiles file using its native strengths, and then serves it up in the classic Z/X/Y format that the ArcGIS SDK loves.
Z/X/Y
Talk is cheap, right? Here’s a quick video showing what our PMTiles look like, rendered beautifully inside an Esri JavaScript API map.
Ready to stop reading and start coding? We’ve made it incredibly easy for you to get this up and running on your own. No complex setups, we promise.
Here’s a Jupyter notebook hosted in Wherobots that walks through the process, from grabbing geographic data to creating your own optimized .pmtiles file. ➡️ Click here to access the Jupyter notebook
.pmtiles
Next, let’s start the "translator" service we discussed. We’ve open-sourced a lightweight tile server on our GitHub repository. Clone the repo, follow a few simple setup steps, and you’ll be serving your PMTiles to the Esri SDK in minutes. ➡️ Get the code on GitHub
Dive in, play around with the code, and see for yourself how powerful this combination can be. We can’t wait to see what you build! If you have questions or ideas, feel free to open a new discussion thread on GitHub. Better yet, if you’d like to help improve the project, we welcome all contributions to the repo.
Introducing RasterFlow: a planetary scale inference engine for Earth Intelligence
RasterFlow takes insights and embeddings from satellite and overhead imagery datasets into Apache Iceberg tables, with ease and efficiency at any scale.
Wherobots and Felt Partner to Modernize Spatial Intelligence
We’re excited to announce Wherobots and Felt are partnering to enable data teams to innovate with physical world data and move beyond legacy GIS, using the modern spatial intelligence stack. The stack with Wherobots and Felt provides a cloud-native, spatial processing and collaborative mapping solution that accelerates innovation and time-to-insight across an organization. What is […]
Scaling Spatial Analysis: How KNN Solves the Spatial Density Problem for Large-Scale Proximity Analysis
How we processed 44 million geometries across 5 US states by solving the spatial density problem that breaks traditional spatial proximity analysis
Wherobots brought modern infrastructure to spatial data in 2025
We’re bridging the gap between AI and data from the physical world in 2026
share this article
Awesome that you’d like to share our articles. Where would you like to share it to: