The gap between desktop GIS and browser-based mapping is closing fast. WebGIS solutions are increasingly taking on tasks that previously required dedicated desktop environments, such as complex analytical processing, on-the-fly integration of massive datasets, and workflow automation. While proprietary systems have provided monolithic solutions for these tasks, the open-source ecosystem is now catching up with more flexible, modular approaches.

Here, we introduce GOAT, a refactored WebGIS platform built to bring analytical processing to the browser using modern open-source technologies. Traditionally, spatial analysis workflows are fragmented. Data is found on web portals, downloaded, processed locally, and eventually pushed back to a visualization tool. GOAT is designed to consolidate this cycle. Users can search and load data via built-in catalogs, direct uploads, or OGC services, and apply styling directly in the browser. Beyond basic mapping, the application provides spatial modules for travel-time calculations, geostatistics, and general geoprocessing. To support reproducibility, processing steps can be chained together in an automated workflow builder. This allows users to rerun complex analyses when new data arrives or parameters change, and includes support for custom SQL queries. These workflows can also be mapped to UI inputs on the map, allowing non-technical users to execute spatial pipelines by adjusting parameters.

Once the analysis is done, results need to be shared. GOAT includes a layout engine for designing and exporting high-resolution map series and PDFs. A dashboard builder lets users combine maps with charts and metrics. Because the dashboards remain linked to the underlying data, they update automatically when the data changes, turning static reports into interactive tools.

Under the hood, the project is freely available under the GPL-3.0 license and managed as a monorepo. The frontend relies on React.js, Next.js, and MapLibre GL JS, communicating over modern OGC protocols (Tiles, Features, Processes). All endpoints are built in Python with FastAPI, following both OGC standards for spatial services and the OpenAPI specification.

For geoprocessing and data management, the FastAPI backend leverages Python and PostgreSQL/PostGIS. One of our recent architectural shifts is the implementation of DuckLake, a framework that combines the storage efficiency of Parquet files with the analytical speed of DuckDB, alongside PostgreSQL for metadata. Due to scaling issues with PostgreSQL/PostGIS on large datasets and growing volumes of user data, we adopted this hybrid approach. Parquet files allow us to store and query large spatial datasets efficiently, while DuckDB provides the processing speed needed for analytical workloads. This structure enables data to be stored in comparatively cheap volume storage and easily backed up in S3-compatible object storage.

For serving data, we implemented a hybrid vector tile architecture. We rely on static vector tiles generated by Tippecanoe for maximum rendering speed, while dynamic vector tiles are created on the fly using DuckDB for filtered or edited datasets. In practice, this means we can render and interact with millions of building footprints or land-use parcels directly in the browser through pre-generated tiles, yet still maintain the flexibility to request dynamic tiles when users modify data or apply filters.

To prevent large analytical queries from slowing down the application, we adopted an asynchronous architecture using Windmill to orchestrate Python jobs in the background. Long-running geospatial tasks are defined in a core library powered by Python and DuckDB. Each tool is wrapped as a standard OGC Process, making it accessible from both the frontend and external APIs. This design ensures that processes run in isolation, meaning individual tools can be scaled independently based on their specific resource demands. As a result, users can chain multiple processing steps into background workflows and continue interacting with the map uninterrupted. Finally, the entire platform is Dockerized and deployed via Kubernetes to ensure robust scaling in production.

We have also built dedicated data pipelines to ingest base data, such as street networks from OpenStreetMap, spatial features from Overture Maps, and public transit schedules via GTFS. Active mobility is handled by custom algorithms, while public transport routing is powered by the open-source Nigiri engine (from MOTIS). This combination allows users to run complex, large-scale spatial queries like spatial intersections, identifying gaps in public transit networks, or evaluating nationwide accessibility.

In this talk, we will share the technical challenges we faced and the architectural decisions we made while building GOAT. Although GOAT has been primarily developed by Plan4better, a core goal of this presentation is to encourage participation from the wider open-source geospatial community. Alongside a live demo, we will discuss practical use cases in Germany. Finally, we will touch on our latest technical experiments, such as integrating locally hosted open-weight LLMs to help users query spatial data via plain text, and outline our roadmap for deeper integration with existing open-source GIS tools like QGIS.