The Quiet Rise of Cloud-Native Geospatial Data Formats
April 29th, 2026 | by Michael Scholz
(6 min read)
In former days, the Open Geospatial Consortium (OGC) has been fueling interoperability between spatial data providers and distributed consumers through their OGC Web Services (OWS), of which the Web Feature Service (WFS) and Web Coverage Service (WCS) are the most prominent ones when it comes to data provision. With their transition towards more modern OGC APIs, OGC’s current work focuses on being in line with developer-friendly web APIs — also by following the trend of “less XML, more JSON”. Even though the technical wrapping is modernized with OGC APIs in comparison to OWS, still, the core concept behind data distribution prevails:
Your data has to be published through a purpose-made, standards-implementing geospatial data server in order to be consumable by a client which is talking the very same specific standard interface.
For GEONATIVES, this might not be of any surprise and for sure, it also should not be any show-stopper because “it’s the same procedure as with every OGC standard”, right? But, here, a new trend enters the playground for geospatial data exchange, with the potential to disrupt at least some of our common application use cases and workflows.
We are talking about the quiet rise of cloud-native geospatial data formats. Their collective goal lies in eliminating the component of a “purpose-made server” in your data distribution pipeline. But, why? Because such a specific server has to be dedicatedly developed for supporting these OWS or OGC API standards and thus imposes additional overhead in configuration, deployment, maintenance, scalability, etc. Cloud-native formats want to simplify that. Why not using a plain off-the-shelf HTTP web server such as Apache or nginx for publishing your static file-based datasets from a network share (NFS)? Or, why not simply dropping your files into an S3 bucket in your on-premise or remote cloud and letting the HTTP protocol do all the data distribution work for you?
With regular file-based formats for raster and vector data, using plain HTTP will quickly become a bottleneck on provider and consumer side because, as we all know, geodata tends to be big in file size. At the same time, often only chunks of the original data are required for specific analysis or application cases. Querying such selective chunks in a performing way mostly always requires accessing the spatial index of a dataset, which, without fancy hocus-pocus, is possible only after having downloaded the whole file. Here, a “purpose-made spatial data server” is simplifying our lives by elegantly abstracting all these access details. On the one hand, this is adding the burden of an OGC standard application layer. On the other hand, we have to be honest, it will also add various comfort functionality for interaction with the underlying raw data (e.g., server-side geometry manipulation) which can be highly valuable in more complex or flexible application scenarios.
Now, in the cloud-native case which completely omits this server component, a different approach is becoming handy: With the feature of range requests — which we all know from the ability to resume interrupted downloads — also geospatial file-based datasets can be served well-performing over HTTP. Such precise byte range requests enable the requesting client to make use of spatial indices and internal data generalizations — such as resolution pyramids of raster data — without having the need to download the whole dataset in advance. But, how does a client know which byte range corresponds to which precise data chunk on the remote end? Those cloud-native geospatial data formats are self-describing through the information provided in their header/footer. As example, by loading them into a GIS application, the coordinate bounding box of a current map frame can be translated on-the-fly to the targeted HTTP byte range for just requesting the desired data chunks from the server. This even allows for parallelized data access! The summarized difference is that when using OWS or OGC API, the server performs all spatial filtering, etc., and when using cloud-native formats, the spatial filter is executed entirely client-side against a locally-cached index. This index is acquired in the very first run when accessing the remote file.
| Purpose | OGC Web Service | OGC API | Cloud-native format |
| Serving vector raw data | WFS | API – Features | FlatGeobuf |
| Serving raster raw data | WCS | API – Coverages | COG |
| Serving map tiles | (WMTS, raster output) | API – Tiles | PMTiles |
On the German FOSSGIS conference 2026, Isabelle Korsch and Johannes Kröger introduced some of the rising cloud-native geospatial data formats in their hands-on demo session Moderne Cloud-Daten in QGIS. Just following their screen play gives a good feeling for the potential behind the cloud-native concept. If you are also planning to get your hands cloudy, the Cloud-Optimized Geospatial Formats Guide will help getting a more detailed overview.
Apart from FlatGeobuf, Cloud-Optimized GeoTIFF (COG), and PMTiles which — purpose-wise — find direct counterparts in OGC web standards, other interesting HTTP-native formats are to be mentioned:
- Similar to the COG, which in the end is just an internally restructured GeoTIFF file, the Cloud-Optimized Point Cloud (COPC) is a more efficiently structured LAZ file. It enables you to serve highly dense LiDAR data at a global scale and to make it smoothly loadable in arbitrary web or mobile mapping applications.
- And, ultimately, the OGC 3D Tiles standard is there to integrate them all! If you wanted to create an overall 3D web mapping application, you could scrape together all your sourcing spatial vector, elevation, point cloud and building model data and convert them to a 3D tiles database for streaming it to the client. This approach is even applicable to OBJ files known from classic 3D modeling contexts which usually come without spatial referencing information. You would still have to position those objects correctly “in the scene”, as Martin Alzueta shows in minute 8 of his FOSSGIS presentation Open Source Tools zur Erstellung von 3D Tiles – Erfahrungen und Herausforderungen.
Too good to be true? What’s the catch with those cloud-native geothings? First of all, these formats are primarily designed to stream static data efficiently to a requesting client in a read-only manner. The whole concept of serving one large file and just enabling fast and selective access to parts of it breaks in the very moment where anybody wants to change parts of the dataset. As for now, changes will require re-creation of the whole file and the file’s self-describing metadata will also have to be rebuilt with any incoming update of the internal structure. In contrast to this, some of the OGC web standards offer bi-direction data handling through transactional support. Not to mention all the convenience functionality offered by the extended OWS and OGC APIs such as supporting server-side data queries, attribute-based filtering or on-the-fly coordinate reference system transformations (reprojection).
Regarding coordinate reference systems (CRS) one could ask which CRS these cloud-native formats are using? The general approach is similar to common spatial data formats and depending on the data creator or publisher. In many cases, you can freely choose your CRS, but you should always persist your choice in the metadata or header of your data in order for the coordinates to be correctly interpreted by any consuming application. Two exclusions of this freedom of choice are PMTiles, which stick to the web-common Pseudo-Mercator (EPSG:3857) projection which we know from OpenStreetMap, and OGC 3D Tiles which want to be referenced in our planet earth’s geocentric 3D coordinates (EPSG:4978).
Another aspect of consideration is the map styling for visualization purposes. This article focuses on how cloud-native formats can simplify transferring the actual data from a provider to a client. So far, we have not been talking about the “look and feel” of the served data. Here, the cloud-native approach underlines the current paradigm shift away from server-side rendering, also known as “the data owner decides how his content is to be rendered” to client-side rendering, known as “everyone decides for themselves how the content should be rendered”. For example, in contrast to a Web Map Service (WMS), which would apply styling information for the requested map tile on the server and just return a colorful bitmap representation of the underlying vector data, the approach of client-side rendering could request the actual vector data through WFS, OGC API – Features, or FlatGeobuf and implement a custom styling in the application.
Having said that, we wish you fruitful discussions with your spatial data backend team while refactoring all your painfully established data provisioning pipelines towards the cloud-native approach 😉.
About The Author
