Introducing Geobble: From Geographic Data to Maps Ready to Publish

Most geographic work begins long before a map appears.

It may begin with a planning document, a PostGIS table, several public datasets, an incomplete asset register, or a question whose spatial meaning has not yet been defined. Someone has to determine which information is relevant, prepare it for analysis, choose an appropriate method, inspect the result, decide how it should be represented, and eventually turn it into something another person can understand and use.

GIS software already provides powerful ways to perform many of these tasks. The difficulty is often the path between them.

Data preparation may happen in a spreadsheet or script. Analysis may happen in a desktop GIS, a notebook, or a database. Decisions may be recorded in messages or remembered only by the analyst. Styling may begin after the analytical context has already been lost. Publication may produce a screenshot, an exported file, or a web map that no longer clearly communicates where its data came from or how it was created.

Each tool can work correctly while the overall workflow remains fragmented.

Geobble was built around the idea that this continuity matters. It is a browser-based geospatial workspace for moving from raw geographic information to reusable spatial data, reviewable analysis, carefully refined maps, and published resources.

The Map Is Only One Stage of the Work

A visible map is often treated as the final proof that a geographic workflow succeeded. In practice, a map can look complete while important questions remain unanswered.

Which data was used? Was it current? Were missing attributes inferred, imported, or entered manually? Which spatial operations produced the result? What assumptions shaped the classification? Is the map intended for exploration, decision-making, public communication, or internal review? Can someone update it without reconstructing the entire process?

These questions become more important as GIS workflows incorporate AI.

An AI system can reduce the time between a question and a plausible first result. It can help identify useful data, suggest an operation, produce an initial classification, or prepare the first version of a map. But speed does not remove the need to understand the inputs, inspect the transformation, and decide whether the result is appropriate for its intended audience.

A useful GIS platform therefore needs to support more than map generation. It needs to preserve the relationship between data preparation, analysis, cartographic decisions, collaboration, and publication.

That is the workflow Geobble is trying to connect.

A Workflow Organized Around Sources, Projects, and Studio

Geobble is organized around a small number of resource types and working environments, each corresponding to a different part of geographic work.

A Source is reusable geographic data. It may be uploaded from a supported GIS file, imported from PostGIS, produced by an analysis, or created through a data-preparation workflow. A Source is not merely a temporary attachment to one conversation. It can be inspected, reused in different Projects, opened in Studio, related to other resources, and published when its licence and permissions allow it.

A Project is where a geographic question is explored. It brings relevant Sources and other context together so that a user can investigate a problem, request spatial operations, compare results, and develop the first version of an analysis or map.

Studio is the direct working environment. It is where users manipulate Sources, organize layers, adjust symbology, refine labels, inspect details, collaborate, and prepare a map for its intended audience.

These surfaces are connected, but they are not interchangeable. Exploratory reasoning and production editing require different kinds of interaction. A conversation is useful when the question is still developing. Direct manipulation becomes more useful when the user knows that a class boundary, label, layer order, or visual hierarchy needs to change.

A typical workflow might look like this:

Bring existing geographic data into Geobble or create a new Source from supported information.
Use a Project to investigate a spatial question and generate an initial result.
Review the operations, assumptions, and resulting data.
Open the work in Studio for direct cartographic refinement.
Keep the result private, share it with collaborators, or publish it for a wider audience.

The stages are not a mandatory linear pipeline. A user may begin directly in Studio, return from Studio to further analysis, reuse one Source across many Projects, or create several maps from the same underlying data. The purpose of the model is not to constrain the work, but to keep its parts connected.

Geographic Work Does Not Always Begin With Analysis-Ready Data

Many GIS workflows begin with data that is incomplete, inconsistently structured, or not yet geographic in the form the project requires.

A table may contain asset names but lack useful geographic attributes. A report may describe sites, boundaries, or observations that still need to become structured features. An existing Source may need additional information before it can answer the question at hand.

Geobble treats this preparation as part of the geographic workflow rather than an invisible prerequisite.

With Extract Features, supported documents or records can be examined for information that may represent geographic features. The result is presented as a proposal that can be inspected before it becomes a reusable Source.

With Enrich Source, existing features can be supplemented with proposed attributes or geographic information. Again, the goal is not to silently modify authoritative data. Proposed changes are reviewed before they are accepted.

This distinction matters because generated data can be plausible without being correct. Names may be ambiguous. Documents may omit context. Two records may refer to the same place. An inferred attribute may be useful for exploration but unsuitable for publication without independent verification.

Data preparation becomes more useful when its evidence, uncertainty, and decisions remain visible.

Once reviewed, the resulting Source can participate in the rest of the platform. It can support analysis in a Project, be refined in Studio, contribute to a map, or be published with appropriate metadata and limitations.

AI Can Accelerate the First Draft, Not Replace Geographic Judgement

There is a tempting version of AI-assisted GIS in which the user describes a map and receives a finished answer.

That model is attractive because it makes a complex process appear simple. It is also incomplete.

A map is shaped by decisions that cannot be judged solely by whether the output looks convincing. A classification can exaggerate or hide variation. A colour ramp can imply an order that does not exist. Labels can obscure the features that matter. A technically valid buffer or spatial join can still answer the wrong question. A dataset can be accurate and still be inappropriate for the time period, geography, or audience.

Geobble uses AI to shorten the path to a useful first result while keeping that result available for inspection and refinement.

In a Project, the assistant can help users work with the available context, prepare spatial operations, and construct an initial map or derived Source. The output does not have to remain trapped inside the conversation. It can move into Studio, where the user works directly with the data and map specification.

This separation reflects a practical view of AI in cartography: generation and judgement are related, but they are not the same activity.

The first draft may come from a prompt. The final map still benefits from someone deciding what deserves emphasis, which uncertainty should be disclosed, how much detail the audience needs, and whether the representation is faithful to the underlying geography.

Start with AI. Finish with craft.

Review Is Part of the Workflow

A spatial result should not become trustworthy merely because a system produced it successfully.

The user needs to know what data participated in the work, what operation was proposed, what the result contains, and which decisions still require human validation. This is especially important when a workflow creates new geographic features, enriches an existing Source, derives data through spatial analysis, or prepares something for publication.

Geobble is therefore designed around reviewable actions.

Reviewability does not mean that every workflow must become slow or bureaucratic. It means that consequential changes should remain understandable. Inputs should be identifiable. Proposed work should be distinguishable from accepted work. Generated data should not silently overwrite its source. Results should remain editable. Permission and publication decisions should be explicit.

This is also why Geobble does not treat AI as a separate destination inside the product. AI assistance participates in a larger resource workflow. The useful output is not the conversation itself, but the Source, analysis, map, or decision that emerges from it and can still be examined afterwards.

Review does not guarantee correctness. It creates the conditions in which correctness can be assessed.

Publication Should Preserve the Identity of the Work

GIS workflows often end by disconnecting the output from the process that created it.

A map becomes an image in a report. A dataset becomes another file with a slightly different name. A web link remains available, but the relationship between its layers, source data, purpose, and owner is difficult to recover. When someone wants to update or reuse the work, they may have to reconstruct its history manually.

Geobble treats Maps and Sources as persistent resources rather than disposable exports.

They can have ownership, visibility, metadata, provenance, related resources, and a stable place within the platform. A public map can remain connected to the Sources and context that help explain it. A public Source can be discovered and reused where its permissions allow. Related Maps, Sources, Collections, and articles can form a body of geographic work rather than a set of isolated links.

Publication is therefore not only the moment when a map becomes visible. It is the point at which the work acquires a public identity and a relationship with its audience.

This idea will be explored more deeply in a separate article on map identity. For Geobble, it already influences how resources are owned, shared, related, remixed, and published.

What Geobble Supports Today

Geobble currently connects the main stages of this workflow.

Users can create Projects, upload or import Sources, use those Sources as analytical context, request spatial work, inspect derived results, and carry maps into Studio for direct refinement. Studio includes map editing alongside data-oriented workflows such as feature extraction and Source enrichment.

Maps, Sources, and Collections can be kept private, shared with permitted collaborators, or published when the owner is ready. Public resources can lead into meaningful actions such as analysing a Source or remixing a Map, while preserving that intent when authentication is required.

The platform also records resource relationships and editorial context so that public geographic work can be accompanied by explanations, related data, and relevant maps rather than presented as an unexplained endpoint.

This does not mean that every GIS workflow should happen in Geobble.

Geobble is not an attempt to reduce the entire discipline to a chat interface, replace every specialist desktop tool, or imply that AI removes the need for domain expertise. Some work requires dedicated scientific software, custom code, specialised databases, field systems, or analytical methods that belong elsewhere.

The goal is narrower and, we believe, more useful: to provide a connected environment for the substantial class of workflows that move from geographic information through preparation and analysis to a map or Source that other people can review, refine, reuse, and publish.

The product is still early in its public life. Its direction will be tested not by the number of capabilities it can list, but by whether real users can complete real geographic work without losing context between the stages.

A Geographic Question Is the Place to Start

The name Geobble comes from Geographic Bubble, or Geographic Bubbles.

A geographic bubble is an area whose places are connected by more than proximity. They may share an elevation range, climate, culture, administrative identity, level of access, exposure to a risk, or another spatially meaningful condition.

Some bubbles resemble familiar geographic boundaries. A contour line encloses places that share an elevation threshold. An isochrone groups places reachable within a given travel time. A watershed, service area, language region, heat zone, or neighbourhood can each describe a different kind of geographic bubble.

Others are less obvious. They may overlap, change over time, or only become visible when several Sources are analysed together. The same location can belong to many bubbles depending on the question being asked.

Geobble is built for exploring, creating, comparing, and communicating these spatial relationships. The simplest way to understand the platform is therefore not to begin with its feature list, but with a real geographic question.

Bring the relevant information together. Determine what still needs to become structured data. Explore the question in a Project. Inspect the result. Refine the map in Studio. Publish it only when it communicates what you intend, or raise the questions you want to ask.

The map is important, but it is not the whole workflow. It is one way of making a geographic bubble visible, understandable, and useful.

The best way to see how that workflow feels is to begin with a question of your own.