Anaximander: Interactively Running Geospatial Deep Learning Models on Any Compute Backend

1. Introduction

• Integration work, rather than inference itself, is the dominant bottleneck when evaluating heterogeneous models on satellite imagery.Each model may require format-specific deployment, tile-aligned inference, coordinate transformations, result assembly, and GIS layer registration.Source: §1 · p. 1
• Anaximander separates model source from compute location behind one interface, while the QGIS plugin handles tiling, georeferencing, reassembly, and live per-tile status.The interface also includes Quick Labels, which turns a QGIS layer legend into a structured prompt for a vision-language model.Source: §1 · p. 2
• The system unifies four model-source families and four compute backends; its inference backend and protocol are open source, while the plugin release is pending.The backend serves PyTorch, ONNX, and HuggingFace models over gRPC and reaches cloud APIs over HTTP.Source: §1 · p. 2
• A three-model agricultural field-delineation case study demonstrates code-free comparison across a cloud vision-language API, a remote GPU, and a local CPU.The three-model comparison is presented as a case study, not as a benchmark in the supplied passages.Source: §1 · p. 3

2. Related Work

• The surveyed tools each have at least one constraint in supported model sources, inference task, or execution location; remote execution, when offered, is limited to one model family.The passage also reports that no surveyed tool lets practitioners direct the same inputs to multiple models while choosing the inference location.Source: §2 · p. 3
• No surveyed project combines source-agnostic remote delegation with a tile-streaming protocol and server-side session state.Where remote execution exists, it is exposed as isolated per-request calls rather than a protocol for streaming a tiled raster.Source: §2 · p. 3
• The authors argue that generic inference-serving wrappers are insufficient because geospatial inference must manage session and tile semantics, geographic metadata, and inputs from different imagery sources.They implement these operations on GDAL, which ships with QGIS, rather than adding a geospatial dependency to the user's QGIS installation.Source: §2 · p. 3

3. Architecture

• The QGIS plugin and nxmndr server communicate over a reusable gRPC protocol, allowing other clients such as notebooks, batch pipelines, or web applications to provide interactive inference.The system consists of the server, which loads models and runs inference, and the plugin, which drives the server from QGIS.Source: §3 · p. 3

3.1 Inference Backend (nxmndr)

• A bidirectional stream carries tile chunks over one server connection and returns one response per completed tile, with session and tile identifiers, timing, and serving-device information.This collapses thousands of tile submissions into a long-lived stream, avoiding the connection setup cost of a unary call per tile.Source: §3.1 · p. 5

3.2 Model Specification

• ModelSpec registers model format and source declaratively, allowing the cache, session layer, and dispatcher to remain agnostic to the model family.The server also decodes dense outputs and instance masks by result family; the case study exercises the instance path for SAM 3 and DelineateAnything.Source: §3.2 · p. 5

3.3 QGIS Plugin (nxmndr-qgis)

• The plugin lets users select imagery, models, task, bands, tile size, stride, and compute provider, then runs tile requests as a background QGIS task with live tile-status updates.The server negotiates how many tiles may be in flight, and cancellation stops new reads, ends the stream, and cancels the session.Source: §3.3 · pp. 5–6
• Completed predictions are written into georeferenced raster windows and added to the QGIS project as they arrive; Quick Labels separately sends legend-driven prompts and imagery to a cloud vision-language model.For compositing, each tile may be predicted with surrounding context, while only its centered output window is written; partial edge tiles are padded and cropped back after inference.Source: §3.3 · p. 6
• Because each output pixel comes from one tile with no blending, a parcel crossing a seam can remain correctly delineated as area but appear as two instances.The authors expect users to recenter a seam-split object and run a smaller-scale inference call rather than rely on general stitching.Source: §3.3 · p. 7

4.1 Setup

• Across runs, all three models received identical pixels from a 1,024 × 1,024-pixel crop; tiled runs used the default 512-pixel chips with no overlap, yielding four tiles.Source: §4.1 · p. 7

4.2 Cloud API: gpt-image-1

• gpt-image-1 returned some parcel outlines but with substantial boundary inaccuracy after a structured prompt requested a color-coded instance-segmentation mask.The model was accessed through Quick Labels rather than the tiled inference pipeline.Source: §4.2 · pp. 7–8

4.3 Remote GPU: Segment Anything Model 3

• Unprompted SAM 3 produced fragmented masks over roughly a third of the scene, often covering partial parcels rather than whole fields.The authors state this is an expected zero-shot outcome, not a fair evaluation of SAM 3; deploying the gated model to a remote GPU took a similar sequence of clicks as the cloud path.Source: §4.3 · p. 8

4.4 Local CPU: DelineateAnything

• DelineateAnything captured most visible parcels with tight boundaries, with artifacts where parcels crossed non-overlapping tile edges.This local-CPU run tested tiled output assembly and georeferencing and served as the qualitative baseline for the two foundation-model runs.Source: §4.4 · p. 8, Figure 3 · p. 9

4.5 Observations

• The same plugin UI ran three models on identical imagery and placed georeferenced outputs in one QGIS project without integration code; this was a qualitative demonstration, not a benchmark.The outputs illustrate the comparison workflow, not model accuracy.Source: Figure 3 · p. 9, §4.5 · p. 9

5. Limitations

• The protocol assumes a single-resolution image tensor and square tiles, excluding models that need image pyramids, auxiliary inputs, or non-image inputs such as point clouds and vector features.Supporting those inputs would require changes to the server streaming schema and plugin tile-generation logic.Source: §5 · p. 10
• Each tile writes a non-overlapping window without probability blending or cross-tile instance reconciliation, so objects split at tile edges appear as separate instances.The authors note visible seams in the DelineateAnything output.Source: §5 · p. 10
• Anaximander supports inference only, and catalog models must include their training-time scaling and normalization because the server sends chips unscaled and unnormalized.Users must train or fine-tune models externally and export weights in a supported format.Source: §5 · p. 10

6. Conclusion

• Anaximander unifies four model-source families and four compute backends behind a QGIS plugin, with gRPC for served models and HTTP for cloud APIs.Users can extend both the model zoos and compute-backend capabilities.Source: §6 · p. 10
• The case study ran three source-and-compute combinations on one agricultural scene without integration code, with georeferenced outputs in the same QGIS project.The combinations were a cloud vision-language API, a HuggingFace foundation model on a remote GPU, and a YOLO variant on a local CPU.Source: §6 · p. 10
• Future directions include non-RGB imagery, multi-scale and non-image inputs, active-learning loops, managed deployment templates, and agentic model selection.The proposed agentic direction would use the same gRPC surface to query the model registry and stream tiles through selected models.Source: §6 · p. 10

Appendix 1. User Interface Walkthrough

• The walkthrough covers locating the plugin, configuring credentials and server endpoints, browsing and selecting a model, and running inference on a raster.Source: Appendix 1. User Interface Walkthrough · p. 12

• Choosing “Browse models” or “Quick Labels” activates a dock widget for configuration.The settings action opens a separate dialog.Source: Menu entry and panel location · p. 12
• A “Models” drop-down in the QGIS menu bar is the plugin’s entry point.The menu is shown in Figure 4a.Source: Figure 4 · p. 12, Menu entry and panel location · p. 12
• The dock panels appear on the right-hand side of the QGIS main window.This location is shown in Figure 4b.Source: Figure 4 · p. 12

Plugin settings

• Four settings tabs cover service sign-ins, deployed nxmndr addresses, the Quick Labels endpoint, and the local worker environment.The endpoint can be OpenAI or Azure OpenAI, and the Runtime tab is not shown in Figure 5.Source: Plugin settings · p. 12, Figure 5 · p. 14

Model browser

• The browser offers Saved, Hugging Face, and Local tabs, with saved entries capped at twenty per provider.Each tab emits the same selected-model payload; source-derived keys collapse duplicates, and the plugin checks server compatibility before session loading.Source: Model browser · pp. 12–13

Inference configuration

• Standard inference configures tiled tasks through the server, while Quick Labels sends cloud vision-language requests from the local worker and can inject legend-derived class definitions into prompts.Standard inputs include a raster, task, band mapping, chip size and stride, and compute provider.Source: Inference configuration · p. 13

Appendix 2. Case Study Details

• The gpt-image-1 case-study prompt requests a same-resolution instance mask with a distinct solid RGB color per field and a neutral background.It specifies separate instances even for adjacent or similar-looking fields, with no labels, borders, or legend.Source: gpt-image-1 prompt · p. 13