Geospatial indicators are often built as one-off workflows. A developer writes a script for a particular study area, dataset, spatial unit, or research question; then, when the same metric needs to be reused somewhere else, much of the surrounding logic has to be rebuilt. How should the region be represented? Does the metric work for a city block, a municipality, or an entire state? What parameters are required? What should the output look like? How should downstream users know whether they are calling the metric correctly?

This talk presents an AGPL-licensed, contract-driven API for geospatial indicators in Mexico. The project was built around a simple goal: help geospatial data scientists and developers focus on the substance of the metric they are creating, while the platform handles the repetitive machinery required to expose that metric reliably. The hard part is not only computing an indicator once, but making it reusable across different geometries, spatial scales, data sources, and downstream workflows.

The central idea is a contract between a metric and the execution layer. A developer defines what the metric does, what spatial inputs it accepts, what parameters it requires, what outputs it produces, and how the computation should be run. Once a metric declares the spatial inputs and assumptions it supports, the execution layer can run it consistently across supported spatial units and regions. This separation lets developers write metric logic once while relying on a common interface for validation, execution, and results.

This is not a platform for one specific kind of indicator. The metrics currently available reflect the areas where our research lab has the most experience, including remote sensing, environment, accessibility, and demographic-adjacent workflows. But the system itself is intentionally metric-agnostic. A metric could describe vegetation, weather, land use, accessibility, infrastructure, economic activity, exposure, risk, public services, or any other phenomenon that can be computed for a spatial region. What matters is not the subject of the metric, but whether it can declare its spatial requirements and follow the implementation contract.

The current implementation is focused on Mexico, but the design pattern is not Mexico-specific. The same contract-driven approach could be adapted to other countries, datasets, and regional geographies. The talk will focus on the geospatial design of this abstraction: how metric definitions make assumptions explicit, how spatial inputs can be normalized before reaching metric code, how outputs can be standardized for downstream analysis, and how this makes indicators easier to reuse across projects and spatial scales.

I will also discuss how this model fits into open geospatial workflows. Metrics can be built using OpenStreetMap-derived data, Python geospatial libraries, spatial databases, raster processing, tabular data, APIs, or external geospatial data and compute services such as Google Earth Engine. The project itself is released under AGPL-3.0, and the talk will discuss both the current implementation and the parts of the pattern that other open-source geospatial projects could reuse.

The presentation will include a technical walkthrough of the developer experience. Rather than focusing on backend infrastructure details, the walkthrough will follow the lifecycle of a metric: defining its contract, registering it with the API, submitting a job for a region, and receiving standardized outputs.

Although the project was designed first for human developers, the same abstraction has produced an unexpected benefit: it is also easy for software agents to inspect and call. Because metrics expose machine-readable descriptions of their inputs and outputs, an agent can discover what indicators are available, decide which ones are relevant to a user’s question, call the API, and combine the results with other spatial data sources. While this wasn't the original motivation behind development, is a very useful side effect of designing developer tools around explicit contracts, standardized schemas, and implementation independence.

The project has been used internally in our research lab setting by a small group of experienced users, and early feedback has helped refine the developer contract and execution model. This talk will share the design decisions and lessons learned from building a reusable geospatial indicators API, with an emphasis on practical patterns that other open-source geospatial developers could adapt for their own domains.