Project

GEON: an LLM-native format for representing places as meaning, not coordinates

An open text format that describes what a place is, how it works and how it feels, rather than where its vertices are. Three reference implementations, bidirectional GeoJSON conversion, and measurably fewer tokens than the format it complements.

Period

2024 to 2026

Status

Active

Role

Author and lead developer

Areas

Open format · GeoAI · LLM · Python · Rust · TypeScript · Semantic data

The GEON Explorer with Nottingham Castle selected on a map, its GEON document in the centre panel and an LLM-generated contextual analysis on the right.
Figure

The GEON Explorer. A place selected on the map, its GEON document rendered beside it, and a language model reasoning over that document rather than over a coordinate array.

  • 3Reference implementationsPython, Rust and TypeScript, each supporting the full 0.1.0 spec including parsing, validation and bidirectional GeoJSON conversion.
  • 5Field categoriesIdentity, Geometry, Semantic, Relational and Temporal, with EXPERIENCE encoding qualities absent from every standard format.
  • 0.1Specification versionPublished February 2026. Versioned and open, designed for community extension rather than as a finished standard.
  • MITOpen sourceCode under MIT, specification under CC BY 4.0, so neither the format nor the tooling can be captured.

The brief

Open a GIS dataset and you get polygons and attributes. Before any useful analysis can start, a planner has to mentally reconstruct what the place actually is from a list of numbers. Ask a language model to do the same thing and it has no way to perform that reconstruction at all.

A coordinate array says nothing about whether a street is vibrant or desolate, safe or hostile, historically loaded or finished last year. Attributes help a little, and standard formats offer them as a flat bag of properties with no hierarchy, no relationships and no indication of what any of it means to the people using the space.

This is not a failure of GeoJSON or WKT. Those formats were built for geometry and they are excellent at it. The gap is that spatial workflows now run through language models, and nothing exists that is optimised for reasoning about place rather than rendering it.

The problem arrived from the other direction first. Building WalkGrid meant scoring 51 environmental features across a hexagonal grid, and every one of those scores had to live in a column because there was nowhere else to put it. A format that could carry the meaning alongside the geometry would have made that system simpler, and no such format existed.

The insight

The move is to treat a place as a semantic object rather than as a shape with labels attached.

GEON takes its cue from TOON, which showed that describing objects by purpose and behaviour rather than by physical properties unlocks substantially better model reasoning. The spatial equivalent is a format where every field name carries meaning, every value is interpretable, and relationships are named rather than implied by coordinate arithmetic.

What that buys is semantic density: reasoning-relevant information per token. A model asked which public spaces near a station suit outdoor dining can actually reason over PURPOSE, EXPERIENCE and ADJACENCIES, instead of attempting geometric computation it was never built for. The token comparison in Fig. 1 is the same argument from the other direction, since a context window spent on coordinate precision is a context window unavailable for thinking.

The second consequence took longer to notice. Because the format is legible to a model in both directions, it supports generative spatial reasoning. Give a model a GEON description of an underused street and it can propose interventions and express them back in GEON, which closes a loop between analysis and design that previously required a human at every handoff.

What it does not do

Experiential fields are observer-dependent, and honestly so. One field visit in February does not capture a place, two researchers will not agree on visual complexity, and no amount of controlled vocabulary makes a subjective judgement objective. The fields record an observation with provenance, which is the strongest claim available and weaker than a measurement.

Human curation is simultaneously the point and the bottleneck. Rich documents require someone who knows the place to sit down and write one, and that does not scale to a city, let alone a country. Generation from OpenStreetMap gets a baseline in place but cannot populate the fields that justify the format.

It is version 0.1.0 with community conventions still forming. There is no governance process yet for vocabulary extensions or domain-specific fields, no empirical evaluation of whether GEON representation measurably improves downstream model performance on spatial reasoning benchmarks, and no temporal, 3D or real-time variants beyond sketches. Calling it a standard would be premature. It is a proposal, versioned so it can be argued with.

How it works

5 stages
  1. 01

    Treat a place as an object, not a geometry

    A GEON document describes one or more PLACE entities. The minimum is three fields: what it is called, what type of thing it is, and where it sits. Everything beyond that enriches rather than qualifies, so a valid document can be three lines or three hundred.

    PLACE, TYPE and LOCATION are the only required fields. UTF-8 text throughout, close enough to YAML to feel familiar on sight.

  2. 02

    Encode how a place is used

    PURPOSE captures what a space is for, expressed as the activities it actually hosts rather than as a land use classification. A market square is civic gathering, events and festivals, and informal commerce, which is three claims a planner can act on and a zoning code cannot express.

    Controlled vocabulary with room for extension, so documents stay comparable without becoming a straitjacket.

  3. 03

    Encode how a place feels

    EXPERIENCE is the distinctive field and the one with no equivalent anywhere else. Openness, enclosure, noise level, visual complexity, social diversity and sense of safety, the last of which can vary by time of day because in practice it always does.

    The vocabulary draws on environmental psychology and space syntax, and on the platial clustering work in PlaceCrafter and PlaceAgents, making concepts like enclosure and permeability machine-readable.

  4. 04

    Make relationships explicit

    Places contain other places and relate to them in ways that matter more than distance. CONTAINS, ADJACENCIES, VIEWSHEDS and PART_OF build a graph connected by meaning rather than by proximity, so a tram stop fifty metres north is a named relation and not a coordinate difference.

    This is what makes GEON repositories traversable as spatial knowledge graphs, with places as nodes and semantics on the edges.

  5. 05

    Stay interoperable in both directions

    GEON does not replace GeoJSON and is not trying to. It can be generated from GeoJSON by enriching coordinates with semantic metadata, and serialised back for any existing GIS tool. GeoJSON handles geometry and rendering, GEON handles meaning and reasoning.

    Bidirectional conversion is a first-class concern in all three implementations, not an afterthought bolted on for compatibility.

Figures

The GEON Explorer showing a token count comparison in which GEON uses significantly fewer tokens than GeoJSON for equivalent place descriptions.
Fig. 1

Token efficiency against GeoJSON for equivalent semantic content. This is the argument in one screenshot: a context window is finite, and a format that spends it on coordinate precision has less left for the reasoning the coordinates were meant to support.

The GEON Builder web interface showing form-based construction of a place description with live validation.
Fig. 2

The Builder. A planner, architect or community researcher can produce a valid document without writing the format by hand or knowing that it has a grammar, which is the point of a format meant to be authored by people.

Fig. 3

Generation from OpenStreetMap. Tags populate PURPOSE and CHARACTER, which gets a repository to a usable baseline quickly, though the experiential fields still need a human. OSM is a source for GEON, not a substitute.

Fig. 4

Documents for a range of Nottingham places, from market squares to transport interchanges. The format holds its shape across wildly different kinds of space, which is the test any general place representation has to pass.

Outcomes

  • Format design is an AI capability question

    The same place, described two ways, produces different reasoning from the same model. That makes the choice of representation a design decision with consequences rather than a plumbing detail. The claim is argued and demonstrated rather than measured, since the evaluation framework that would settle it does not exist yet.

  • Experiential qualities became machine-readable

    Enclosure, permeability, visual complexity and social diversity have decades of research behind them and no route into a data file. EXPERIENCE gives them one, with a controlled vocabulary that keeps documents comparable across authors.

  • Three implementations, one specification

    Python for data science and pipelines, Rust for high-performance parsing and CLIs, TypeScript for web and Node services. All three cover the full 0.1.0 spec, so adoption is not gated on a single language community.

  • Designed to be written by people who are not programmers

    The format reads like a document rather than a data file, so a historian or community researcher can write GEON directly. That is a design goal rather than a demonstrated result, and it matters because the knowledge the format exists to capture mostly sits with people who do not write code.

Stack

Implementations
geon-py (Python), geon-rs (Rust), geon-js (JavaScript and TypeScript)
Capabilities
Parsing, Programmatic generation, Schema validation, Bidirectional GeoJSON conversion
Tooling
VS Code extension (geon-vscode), GEON Builder, GEON Explorer
Planned
MCP server, Unified CLI, QGIS plugin, Browser validator
Foundations
Environmental psychology, Space syntax, Urban design theory, OpenStreetMap
Licensing
Specification CC BY 4.0, Code MIT, Version 0.1.0, February 2026
  • Birmingham Newman University
  • University of Nottingham

GEON was developed across affiliations with Birmingham Newman University and the University of Nottingham. No external funding was received.

Work like this

Start a
conversation →

Available for consulting engagements and research collaborations at this scale. Email james@jameswil.com.