NLGIS.ai open standard · TDI 0.1.0

Tile Design Interchange

TDI is a provider-neutral interchange format for describing the visual intent of tiled and web maps before that intent is compiled into provider-specific styles.

A TDI document is a design brief, not an executable renderer stylesheet. It gives agents, people, and software a shared cartographic instruction set that can be translated into MapTiler, ArcGIS Vector Tile Editor, Mapbox, MapLibre, and other tile systems.

View the NLGIS.ai TDI repository on GitHub ↗

Why it exists

Map styling is often trapped inside one editor, one provider, or one prompt. TDI separates the durable design decision from the implementation details. A brief can describe the intended audience, map purpose, hierarchy, palette, typography, linework, layer semantics, sources, rights, and constraints once, then be compiled for multiple providers.

For humans

Write, review, compare, preserve, and hand off a style direction without needing to know every provider’s layer IDs or expression syntax.

For agents

Use ranked intents, controlled vocabulary, explicit constraints, and provider compatibility to select, adapt, and validate a design brief predictably.

For GIS software

Compile the same intent into native styles, manifests, tokens, and documentation while keeping operational source contracts separate.

Core structure

A conforming TDI brief is organized around the design decisions that should survive a provider change.

Section	Purpose	Typical contents
`name`	Human and machine identity.	Canonical name, alias, genre, era, origin, and inspiration notice.
`description`	Readable design intent.	Summary, design principle, historical context, and misclassification cautions.
`classification`	Machine-guided suitability.	Ranked map intentions, scales, label density, terrain emphasis, dimensionality, and implementation complexity.
`design_tokens`	Visual language.	Colors, typography, linework, symbols, label hierarchy, and behavior.
`layer_semantics`	Provider-neutral layer meaning.	Land, water, terrain, roads, boundaries, buildings, places, POIs, transit, trails, administrative labels, and overlays.
`sources` and `rights`	Research and reuse context.	Source records, attribution, license, preferred map credit, and no-endorsement guidance.
`constraints`	Guardrails for compilation.	Required, preferred, avoid, unsupported, accessibility, and responsive behavior.
`provider_compatibility`	Implementation status.	Provider-specific notes, tests, caveats, and compilation readiness.

How the workflow works

1. Select or author a brief

A person or agent can start from a reviewed TDI style, or describe a new map from scratch. The brief should identify purpose, geography, audience, scale, important layers, and visual character.

2. Research and normalize

An agent may research references and turn the result into the same structured TDI shape. Sources and rights remain explicit rather than being hidden in a prompt or lost during compilation.

3. Choose a provider contract

The compiler combines the TDI brief with a pinned source/template contract. This is where provider layer names, glyphs, sprites, expressions, and native syntax are introduced.

4. Validate the compiled artifact

The output can be checked for schema shape, required layers, attribution, accessibility constraints, and provider-specific compatibility. Rendering and editor acceptance should be reported separately from structural validation.

Minimal conceptual example

{
  "spec_version": "0.1.0",
  "name": {
    "canonical": "Quiet regional reference map",
    "alias": "The Clear Regional Reader"
  },
  "classification": {
    "ranked_intents": [
      {"intent": "reference", "rank": 1},
      {"intent": "thematic", "rank": 2}
    ],
    "scales": ["regional", "local"]
  },
  "design_tokens": {
    "colors": {},
    "typography": {},
    "linework": []
  },
  "layer_semantics": {},
  "sources": [],
  "rights": {},
  "constraints": {}
}

The complete normative schema, vocabulary, conformance rules, and reviewed examples live with the TDI release used by TileStyler.

Open, portable, and honest about limits

TDI is intended to make design intent portable—not to pretend that every provider renders identical results. A compiled style remains dependent on its source schema, available layers, fonts, sprites, glyphs, expression support, and editor behavior. Those differences belong in the compilation report and provider contract.

Preferred attribution: When a compiled map can show design credit on-map, use nlgis.ai. The TDI brief carries the broader rights and attribution record: CC BY nlgis.ai, promptcartography.com, and webmapper.org.