Six ideas we are taking to FOSS4G Hiroshima

Next week the ELEMNT team gives six talks at FOSS4G 2026 in Hiroshima. This post explains what each one is about, in plain language, so you can decide which rooms to sit in. If you are new to any of the technology named here, every term gets a one-line explanation on first use.

FOSS4G is the annual conference of the global open-source geospatial community. It runs Sep 1 to 3 at the International Conference Center Hiroshima, with workshops before and a community sprint after.

Why a young platform sends its engineers this far

ELEMNT is a cloud-native geospatial platform. It went generally available on 2026-07-16 and is in early access.

The formats we build on were not decided in a boardroom. They were argued into existence in rooms like this one. PMTiles, GeoParquet, OGC API, STAC: each one has a hallway at FOSS4G where the people who wrote it are standing. When you build on open formats, showing up is not marketing. It is how you find out what the next version breaks.

So we are bringing six talks instead of a booth. Five are architecture. One is a piece of open source. All six answer the same question: what does geospatial look like when the infrastructure is cloud-native by default?

Cloud-native here means one specific thing. Your data lives as files in object storage, and readers pull the pieces they need directly over the network. It does not live inside a server that has to stay switched on to answer questions about it.

1. The browser as the analytics tier

Tue Sep 1, 14:30, Room4

The problem: a web map slows to a crawl long before the dataset is large. Pan and zoom stutter. The tab freezes.

The usual diagnosis blames the browser. This talk blames the format. GeoJSON, the default way to ship map data to a browser, stores one complete record at a time, as text. Field names repeat on every record. The browser has to read all that text and rebuild millions of objects in memory before it draws anything.

The fix is to store the same data by column instead. All the longitudes together, all the timestamps together, as compact binary blocks. That is what Apache Arrow does for tables and what GeoArrow adds for geometry.

Three open pieces then fit together with nothing in between. Parquet, a compressed columnar file format, holds the data in object storage. DuckDB-Wasm, a full SQL database compiled to run inside the browser, does the querying. GeoArrow carries the result straight to the graphics card for drawing.

The talk walks the whole architecture and renders more than 10 million records in one tab, with no backend server in the path. It also publishes its measured comparison against the row-based pipeline, which is worth seeing in the room rather than summarized here.

2. A map style you can ask for

Wed Sep 2, 11:00, Cosmos2

Styling a map is not one decision. It is at least five: inspect the data, compute statistics, choose a colour set, write the style expression, then check that it renders.

You can ask a language model to skip all five. It will produce something that looks right. The talk is about the gap between looks right and is right. Did the model compute those class breaks from your actual data, or guess them? Will it guess differently tomorrow?

The answer is to stop asking the model to do arithmetic. Instead, give it tools. A Model Context Protocol server (MCP, a standard way to expose real functions to a language model) reads your data, computes the real statistics, and hands back facts. The model then writes MapLibre Style JSON, the open specification that describes how a map is drawn.

The distinction the talk lands on is the useful part. Valid and right are different tests, and a style that passes only one of them will still be wrong on screen. This runs against open-weight models on your own machine, which matters when the data cannot leave it.

3. Ask a satellite catalog a question

Wed Sep 2, 11:00, Dahlia1

Satellite imagery is catalogued with STAC, the SpatioTemporal Asset Catalog standard. STAC works well and it is precise, which is another way of saying you have to know the query language to get anything out of it.

The obvious move is to put a language model in front. The obvious move is also where most systems go wrong: they let the model produce coordinates. A model that invents a bounding box will draw a confident map of the wrong place.

This talk separates the two jobs. The model turns a sentence into a typed schema and nothing else. That schema holds four things: the kind of event, the place name, the time window, and a flag for when the model is not sure. A separate lookup then turns the place name into real coordinates.

The talk is also honest about what is still open. It is slower than a plain pattern match, the results are not perfectly repeatable, and the place-name lookup needs ongoing upkeep. That last section is the reason to attend. Sessions that publish their unresolved problems are more useful than sessions that do not.

4. Pay for the run, not the idle

Thu Sep 3, 13:00, Room5

Heavy geospatial jobs arrive in bursts. Capacity is bought for the peak. It then sits doing nothing for most of the day.

There are four common workarounds and each has a catch. An always-on pool runs 24 hours a day. Co-locating jobs with your main application starves the main application. Cron batches wait for the next scheduled window. Standard serverless functions hit time limits and memory caps that heavy geospatial work exceeds.

This talk proposes a fifth option: let queue depth be the only signal. When jobs arrive, workers appear. One job gets one worker, which finishes and deletes itself. When the queue empties, the workers are gone.

The stack is entirely open source: Python, GeoPandas, GDAL, NumPy, Redis, Kubernetes. The API is OGC API Processes, the open standard for running geospatial jobs over the web, so the queue is not a private interface you have to learn.

5. Modern GIS on cloud-native infrastructure

Thu Sep 3, 14:30, Room4

The target architecture is well understood by now. Your layer is a file. Parquet holds the features, PMTiles holds the map pyramid in a single file, and both sit in object storage.

From there it is two short paths. The map reads bytes directly out of the tile file over HTTP. Analytics run on request against the same storage. Nothing has to be kept warm in between.

The part worth a session is not the diagram. It is the migration.

Nobody moves a national GIS estate in one weekend, so the talk argues against trying. Move one layer at a time. Serve it from the new path while the old server still answers for everything not yet moved, and verify the two against each other while both are live.

The old server is then never switched off in a single tense moment. It drains, layer by layer, until it is carrying nothing.

The talk is equally clear about where this is the wrong tool. Latency-critical interfaces, write-heavy and transactional workloads, and live editing all still want a database. That honesty is the most transferable part of the session.

6. APIs outlive databases

Thu Sep 3, 14:30, Room5

Feature data services are usually built as one piece: the API and the database welded together. That works until you need to scale one without the other, or move to a different data store, and discover you cannot.

This talk separates them. The API layer, the service logic, and the database adapter become three parts that can each change independently. The public contract stays OGC API Features, the open standard for serving vector features over the web, so nothing downstream notices when the storage behind it changes.

The session introduces Meros, an open-source feature data service the team built on that idea, and walks through the design decisions and the operating trade-offs. The same thinking underpins how ELEMNT serves feature collections: the API is the contract, the datastore is swappable, and you can bring your own.

What we want to learn

We are going to listen at least as much as we talk. Three questions we do not have settled answers to:

• Where is the community actually converging on cloud-native formats, as opposed to where the blog posts say it is.
• What practitioners expect from versioned geodata. Branching, diffing and merging feature collections is in development for ELEMNT, and we would rather hear the requirements now than ship the wrong shape.
• Where the scepticism about language models on geospatial data is sharpest, and whether it is the same scepticism we have.

How to find us

We did not take a booth. That is deliberate: at this conference the hallway is the event, and six sessions plus the sprint gets you further than a table does.

Come to any of the six talks and stay for the questions. We will also be at the community sprint on Sep 4 at Aster Plaza, taking part rather than presenting. If none of that works, mail [email protected].

The full conference programme, including everyone else's sessions, is on the FOSS4G 2026 schedule. We will post notes from each talk during the week on @elemntearth.

Slides for all six sessions are published after each talk. Figures in this post are taken from the presenters' own decks.