Inside real-time AI mapmaking.

Start with intent, not a blank canvas.

Consider an illustrative request: “Show the inspection locations, color them by status, and add a table.” The useful result is not a paragraph explaining how to do that. It is a composition that changes as the conversation progresses.

Honua Studio is a model-agnostic builder for geospatial applications. Its scope goes beyond a map image: layers, styling, views, tables, charts, and analysis can participate in the same application composition.

The starting point is the live catalog and the authority available to the user. A model suggestion is not permission to access a dataset, invent a layer, or change source records.

A tool loop, not arbitrary generated code.

The SDK’s StudioAgentSession declares the available tools, executes model-selected calls, and returns results to the model. The canvas can update as those tool calls stream.

Composition changes pass through a closed command vocabulary. They are applied by the composition reducer or the server’s Studio MCP tools. This is deliberately different from asking a model to emit arbitrary JavaScript and evaluating it in the browser.

Typed commands make the operation explicit: what the agent is trying to change, which parameters it supplies, and how the resulting state can be inspected. An activity log records actions. The model remains fallible; the command contract is an engineering boundary, not a guarantee of cartographic correctness.

Refine the application without editing the data.

The next instruction might change the color scheme or narrow the visible view. Those are changes to the composition, not mutations of the source dataset. This distinction is central to the platform’s AI boundary.

Direct editing of source feature data is excluded from the AI interface. Draft composition and publication are also different actions. Being able to change a draft does not automatically grant authority to publish it.

The current Studio renderer handles vector sources reached through OGC API Features or GeoServices FeatureServer. Raster/image sources and 3D are not part of that renderer’s current scope. Unsupported layers need an explicit explanation rather than a deceptively empty map.

A useful result needs a life beyond the chat.

Studio compositions serialize into the SDK’s package families and use the server’s package lifecycle: drafts, immutable versions, comparison, publication, and rollback. The artifact lives in the platform rather than only in a browser session.

That makes it possible to save and reopen work, compare versions, and govern publication. Governed sharing remains Preview and requires the supported approval path. The existence of version history does not imply that every external side effect is reversible.

Choose the model; preserve the controls.

Studio reaches the configured model through the server’s Studio AI proxy. The operator can choose a hosted provider or a local model; provider keys do not need to reach the browser.

Model choice affects tool selection and map quality. Tests of deterministic fixture conversations are useful, but they are not equivalent to evaluating arbitrary real-model conversations. The implementation documents these evaluation paths separately.

What to evaluate today.

Studio is a self-hosted Preview run from source, not a generally available hosted product. The README distinguishes live model turns, deterministic fixture mode, and release gates.

One particularly important boundary: the Studio GP panel is still connected to a fixture job store. It must not be presented as proof of a complete live Studio-to-batch journey. Server-side GP is a separate implementation and evaluation path.

Start with a supported vector layer and a narrow task. Verify the selected data, fields, styling, save/reopen behavior, permissions, and publication process. Then test additional conversations with your chosen model. Coordinate systems, data quality, and interpretation still require spatial expertise.