Open Geospatial Foundations for a Modern GIS Platform

A modern GIS platform can make geographic work feel remarkably self-contained.

Upload a dataset, run an analysis, design a map, and publish it without leaving the browser. The smoother that experience becomes, the easier it is to forget how many technical boundaries sit underneath it: a database stores the authoritative records, analytical engines transform them, files move between services, tile archives deliver them efficiently, and a renderer turns those pieces into something a person can see and use.

There are many reasonable ways to build those layers. A platform can rely heavily on proprietary formats and tightly coupled services, or it can choose boundaries that remain legible outside the application itself.

Here, we preferred the second approach.

Geobble is built on open geospatial foundations: open-source infrastructure where it provides a strong technical base, open or publicly specified formats where geographic information crosses system boundaries, and internal interfaces designed so that an external provider does not quietly become the definition of a product capability.

This does not mean that every component must be interchangeable at a moment's notice, nor does it mean that a useful product can be assembled just by listing enough open-source projects. Architecture always contains implementation choices, abstractions, and product-specific semantics.

The more important principle is that geographic work should not become unnecessarily opaque merely because it passes through a platform.

Openness Is More Than Open Source

When software describes itself as open, the conversation often begins and ends with source-code licences. Whether users can inspect, modify, and redistribute software is important, but a GIS has other forms of openness that matter just as much to the work people create with it.

A platform may use an open-source database while storing every analytical result in a private format that no other tool understands. It may render maps with an open library while making the underlying data impossible to extract without a proprietary API. It may accept common input formats and then turn the map itself into an object whose meaning exists only inside one renderer.

These systems contain open-source components, but the geographic workflow can still become closed at its most consequential boundaries.

For a GIS platform, openness is therefore better understood as a property of the transitions between systems.

Can the data be represented in a documented format? Can another tool inspect the files without asking the application that created them for permission to decode them? Can the rendering layer evolve without requiring the map's entire identity to be rewritten? Can a routing or geocoding provider be replaced without forcing the product to change the meaning of "route" or "place search"? Can a derived result preserve enough provenance to be understood outside the conversation in which it was generated?

These questions are less visible than a licence badge, but they determine whether a platform becomes an environment for geographic work or a container from which that work is difficult to separate.

Open Formats Create Useful Boundaries

One of the strongest architectural properties of an open format is that it allows two parts of a system to agree on the shape of information without needing to share the same implementation.

Geobble uses GeoParquet as an important analytical representation for geographic data. Apache Parquet already provides a column-oriented format suited to analytical workloads; GeoParquet adds a documented convention for representing geometry and the metadata needed to understand it as geospatial data.[^1]

That matters because an analytical file should not need to know which application will read it next.

A worker can prepare geographic data and write GeoParquet. Another process can query it with DuckDB. A future tool that understands the same format can inspect the same artifact without needing to reproduce Geobble's internal application code. The format becomes a contract at the data boundary rather than an incidental serialization choice.

This is a different role from the transactional database.

PostgreSQL with PostGIS remains well suited to authoritative resource state, permissions, metadata, and source tables where consistency and durable writes matter. GeoParquet serves a different purpose: portable analytical representation that can be moved through storage and queried efficiently without treating the application database as the only place geographic data can exist.

The distinction is useful because openness does not require using one technology everywhere. It requires choosing boundaries that let each technology do the work it is good at without making the whole system depend on its internal representation.

A Published Map Should Not Require a Permanent Tile Server

The same principle appears on the delivery side.

Interactive maps need data in a form that can be requested efficiently as the reader pans and zooms. A traditional architecture often places a tile server between the stored data and every map viewer. That can work well, but it also means the published map remains dependent on an active service that understands how to produce or retrieve each tile.

Geobble uses PMTiles for published tiled artifacts. PMTiles is a publicly specified single-file archive format for tiled data whose current specification is version 3.[^2] A tile pyramid can live as one object in ordinary object storage while clients retrieve only the byte ranges they need.

The important part for this article is not that a single file is inherently better than every tile service. It is that the delivery artifact has a representation of its own.

The archive can be stored, copied, cached, inspected, and served through infrastructure that does not need to understand the semantics of the map. Object storage provides bytes; the client understands the PMTiles archive and requests the relevant ranges. The publication path becomes less dependent on a specialised server remaining in the middle of every interaction.

That separation is useful operationally, but it is also conceptually clean. The geographic artifact does not have to become a live database query simply because someone wants to view it on the web.

A published map may still depend on the application for permissions, metadata, interactions, and other product behaviour. Openness does not imply pretending those concerns disappear. It means avoiding dependencies that do not need to exist.

Rendering Should Be a Capability, Not the Definition of the Map

The renderer is another boundary where geospatial systems can become tightly coupled.

A map has to be drawn somehow, and the renderer inevitably influences which expressions, layers, interactions, and visual effects are possible. The mistake is allowing the renderer's native representation to become the complete definition of the map itself.

Geobble uses MapLibre in its web mapping stack. MapLibre GL JS is an open-source browser renderer for interactive maps and works with vector tiles and the MapLibre Style Specification.[^3] It is a strong foundation for turning geographic data and style rules into pixels.

But, as we argued in A Map Is More Than a Picture, the rendered output is not the whole Map.

Geobble keeps a canonical Map representation above the rendering layer. That representation can describe the Sources, layers, expressions, view, legends, interactions, and other semantic decisions that make the Map what it is. Renderer-specific transformations can then translate the relevant parts into the form required by the current rendering technology.

This boundary is important even when only one renderer is actively used.

Software changes. Rendering engines evolve, browser capabilities shift, and new delivery environments become useful. If the source of truth is the exact object expected by one renderer, every product-level concept eventually inherits that renderer's vocabulary and limitations. If the source of truth represents the map at a higher semantic level, rendering becomes an implementation capability rather than the ontology of the Map.

The goal is not renderer independence in the absolute sense. Every expression ultimately has to become something a renderer can execute. The goal is to avoid surrendering the Map's identity earlier than necessary.

Open Foundations Make Analytical Work Easier to Separate

Spatial analysis has a similar tension.

It is convenient to put data and computation in the same database and let one system become the answer to every analytical question. That design can be appropriate at some scales, but it also couples user-driven analytical workloads to the system responsible for transactional application state.

Geobble separates those responsibilities.

Postgres/PostGIS holds authoritative application and Source state, while analytical and user-authored query work can operate over GeoParquet through DuckDB in isolated execution environments. The query process does not need permanent credentials to the application database or object store; it can receive the specific short-lived access required for the inputs and outputs of the current operation.

The security benefits are important, but so is the architectural effect.

Analysis becomes something that can occur over portable geographic artifacts rather than something that must always execute inside the database that owns the product. The analytical engine can be selected because it is appropriate for columnar and spatial workloads, while the transactional store can be selected because it is appropriate for durable state and access control.

Again, openness is not the claim that every engine can be swapped without engineering work. It is the choice not to make one engine's internal storage model the only representation of the geographic information.

Provider-Neutral Interfaces Matter Too

Not every geospatial capability is naturally implemented inside the platform.

Geocoding, routing, reachability, matrix calculations, and map matching may rely on specialised services with their own data, algorithms, infrastructure, and operational constraints. A platform can integrate those services directly into its product model, or it can place a semantic boundary between the capability the user asks for and the provider that currently fulfills it.

Geobble uses provider-neutral interfaces for these kinds of mobility and place-resolution capabilities.

A Project asks for a route, reachability area, or resolved place in Geobble's terms. The provider adapter translates that operation into the external service's request and normalizes the result back into Geobble's representation. Authorization, cost estimation, provenance, retries, and derived-Source creation remain product concerns rather than leaking into the provider contract.

This kind of boundary is easy to underestimate because it does not correspond to a file format.

Yet it supports the same principle as GeoParquet or PMTiles: a dependency should not acquire more semantic ownership than necessary.

A routing provider may be excellent at routing. That does not mean its payload format should become the permanent definition of a route inside the product. A geocoder may be the current way to resolve ambiguous place names. That does not mean every data-preparation workflow should be designed around that geocoder's private response structure.

Provider-neutrality preserves room to change the implementation while keeping the user-facing geographic concept stable.

Interoperability Does Not Mean Lowest Common Denominator

There is an important failure mode in conversations about open standards.

If every product capability must be representable perfectly in every external format, the platform eventually becomes constrained by the smallest common vocabulary available. Anything that cannot survive conversion is rejected as too proprietary.

That would conflict with the idea developed earlier in this series: a Map should be allowed to remain a Map.

Geobble can support contextual interactions, relationships between Sources, computed behaviour, publication metadata, and other product-level semantics that do not have exact equivalents in GeoParquet, PMTiles, GeoJSON, or a generic style document. Those capabilities do not become illegitimate merely because one export cannot preserve them.

Open foundations should make loss understandable, not impossible.

A GeoParquet export may preserve geometries, attributes, coordinate metadata, and other analytical information while leaving the Map's narrative and interactions behind. A PMTiles archive may preserve the tiled representation needed for efficient display without containing the Project that produced it. A renderer-specific style may carry a substantial portion of the cartographic logic without reproducing every Geobble interaction.

These are not failed exports. They are representations of different parts of the work.

Interoperability becomes more useful when the system is explicit about which semantics cross each boundary and which remain part of the richer Map or Project.

Portability Is Also About the Future

The most practical argument for open foundations is sometimes the least dramatic: systems outlive individual technical decisions.

A format selected today may still contain valuable geographic work years after the application version that produced it has disappeared. A team may adopt a different analytical engine, migrate storage providers, rebuild its renderer, or integrate with software that did not exist when the data was first created.

Open and publicly documented formats increase the number of ways that future can unfold.

They do not guarantee effortless migration. A large platform accumulates semantics that no generic format will reproduce automatically, and durable applications need versioning, transforms, and migration logic of their own. The Geobble Map Specification exists partly because a product still needs a canonical representation of concepts that are richer than its interchange formats.

What open foundations change is the starting point.

A GeoParquet file has meaning outside the process that wrote it. A PMTiles archive has a public specification outside the viewer that requests it. MapLibre can render maps without the renderer being a private black box owned by the application. PostGIS, DuckDB, and other open-source components come with ecosystems and documented behaviour that do not begin and end with one product team.

This reduces the amount of geographic meaning that has to be rediscovered from proprietary internals if the architecture changes later.

Open Does Not Remove Product Responsibility

It would be easy to make the opposite mistake and treat open technologies as an architecture by themselves.

They are not.

Using GeoParquet does not decide how provenance should be represented in the product. PMTiles does not decide which maps should be public. MapLibre does not determine what a legend should communicate. PostGIS does not define the access model for a shared Source. DuckDB does not decide whether an AI-generated spatial result deserves to become durable data.

Those are product decisions.

A platform still needs to define ownership, review boundaries, access control, versioning, map identity, source lineage, collaboration, billing, and the relationship between temporary analysis and published work. Open components provide strong foundations at technical boundaries, but they do not replace the semantic model built above them.

This is why Geobble has its own Map specification even though it relies on open rendering and data technologies. The specification is where product-level meaning can remain coherent while the layers beneath it do what they do best.

The aim is not to avoid creating anything proprietary. A useful product will inevitably contain concepts specific to the problems it is trying to solve.

The aim is to be deliberate about where those concepts begin.

Open Foundations Keep the Product Honest About Its Boundaries

There is a broader reason we care about this architecture.

Geospatial platforms occupy an unusual position between raw evidence and public communication. They ingest data from many institutions, transform it through analysis, and eventually produce maps that may influence how people understand a place. The platform can add considerable value along that path, but it should remain possible to distinguish the value the platform adds from the geographic information it received.

Open foundations help preserve that distinction.

The Source is not valuable only because Geobble can read it. The analytical artifact is not meaningful only because a Geobble worker produced it. The published tiles do not need a private decoder merely because they were generated inside the platform. The visible map is not forced to derive its identity from the rendering library currently responsible for drawing it.

At each boundary, the system can add semantics without pretending to own the underlying medium.

That makes the architecture easier to reason about and creates better exit paths when components need to change.

A Foundation Should Give You Somewhere Else to Go

Vendor lock-in is usually discussed as a procurement problem: how difficult will it be to leave a service?

For geographic work, the more interesting question is what remains understandable if you do.

Can the data still be inspected? Can the published artifact still be decoded? Can another renderer understand enough of the styling or tiles to display the geography? Can derived outputs explain where they came from? Can the platform replace an external service without redefining the user's question around the provider that used to answer it?

No architecture can promise perfect portability across every layer. Geobble itself adds product semantics that other software will not automatically reproduce.

But there is an important difference between having product-specific meaning and unnecessarily trapping basic geographic information inside product-specific containers.

Open geospatial foundations are our way of keeping that boundary deliberate.

We want Geobble to provide a coherent environment for asking spatial questions, preparing data, creating maps, and publishing them. We also want the geographic artifacts underneath that experience to remain as legible as practical to the wider ecosystem of tools from which the platform itself benefits.

A modern GIS should make the integrated workflow feel simple.

Its foundations should not require the rest of the geospatial world to disappear.

Work with geographic data and maps on foundations designed to remain understandable beyond a single application.

References

[^1]: GeoParquet contributors, “GeoParquet Specification, version 1.1.0.” The specification defines geospatial encoding and metadata conventions for Apache Parquet.

[^2]: Protomaps, “PMTiles Version 3 Specification.” PMTiles defines a publicly documented single-file archive format for tiled data.

[^3]: MapLibre, “MapLibre GL JS.” MapLibre GL JS is an open-source web mapping library for rendering interactive maps in the browser.