Glossary
August 26, 2026 · View on GitHub
Two vocabularies meet in this repository. The first describes the map: what an entity is, what a feature is, how feature types are named. The second describes the Python packages that define the schema: workspaces, entry points, specs. Both are collected here.
Terms in the second group are cross-referenced to the page and section that covers them in full — SCHEMA_GUIDE.md for using the schema, AUTHORING.md for extending it, and CONCEPTS.md for background.
Data model
Entity
An entity is a thing in the physical world. It can relate both to physical objects or more abstract concepts that have a spatial presence (e.g. administrative areas are not physical objects as such, but they have physical properties that define their location and extent). An entity can only exist once.
Feature
A Feature is an abstraction of a specific entity in the map. It exists only in its digital form.
Feature Class
Feature Class is a synonym for "Feature Type". The preferred term is "Feature Type".
Feature Type
A Feature Type is a type of entities with common properties as described in the Overture Schema.
Instance
Instance is a synonym for "Feature". The preferred term is "Feature".
Object
Object is a synonym for "Instance" or "Feature". The preferred term is "Feature".
Theme
The top-level grouping a feature type belongs to, and a mandatory property on every
feature. The term is deliberately chosen over "layer" to avoid that word's baggage. There
are six: addresses, base, buildings, divisions, places, transportation. Each
ships as its own Python package, overture-schema-theme-*.
Type
The feature type within a theme, and a mandatory property on every feature — for example
theme=buildings, type=building. Together theme and type identify the feature type.
Subtype
An optional third property that further refines the feature type — for example
theme=transportation, type=segment, subtype=road. Where a type has subtypes, the
model for that type is usually a discriminated union with one arm
per subtype. Note the spelling: the field is subtype, not subType.
GERS
The Global Entity Reference System. A feature's id may be a GERS ID if — and only if —
the feature represents an entity that is part of GERS.
Toolchain
Alias
Three unrelated things in this codebase go by this name. Which one is meant is almost always clear from context, but they are worth separating:
- Field alias — a mapping from a Python attribute name to the name the data uses,
declared with
Field(alias=...). It exists because some data field names are not legal Python identifiers:Building.class_carriesalias="class", sinceclassis a reserved word. Dump withby_alias=Trueto get the data name back. - Type alias — a module-level name bound to a type expression rather than to a class.
Segmentis one: it is anAnnotated[Union[...], Discriminator(...)], not a class. This is whySegment.model_validate(...)raisesAttributeErrorand you needTypeAdapter(Segment).validate_python(...)instead. See Working with Segment and other unions. - Entry-point name — the short name a model registers under, which need not match the
class name.
building = "overture.schema.buildings:Building"registers the classBuildingunder the namebuilding.
Entry point
The mechanism by which a package advertises something to the rest of the installed
environment, declared in pyproject.toml. Nothing imports these directly; they are
discovered at runtime. The schema uses four groups: overture.models (feature types),
overture.tag_providers (tags), project.scripts (the CLIs), and pytest11
(test plugins). Registering your own model is a matter of adding an entry point — see
Register your own feature types.
Workspace
One repository containing several independently-versioned packages that share a single
lockfile and a single virtual environment. Declared by [tool.uv.workspace] in the root
pyproject.toml. The schema repo is a uv workspace of thirteen packages. See
What "workspace" means.
Metapackage
A package that ships no code of its own and exists only to depend on others.
overture-schema is one: installing it pulls in every theme. Its namespace root contains
nothing but a py.typed marker, which is why from overture.schema import Building
fails.
Flat shape
The form a feature takes as a single record with no nesting of core properties — id,
geometry, theme, type and the rest all sitting at the same level. This is the shape
the Pydantic models use, and the shape Overture publishes in Parquet.
model_validate() expects it.
Envelope
The GeoJSON form of a feature, where most properties are tucked under a properties key
alongside a top-level type: "Feature". Distinct from the flat shape, and
the single most common source of confusion when validating: model_validate() rejects it,
model_validate_json() accepts it. See
Two representations.
Discriminated union
A union of models where one field's value decides which arm applies. Segment is
discriminated on subtype: road selects RoadSegment, rail selects RailSegment,
water selects WaterSegment. Pydantic uses the discriminator to pick an arm without
trying each in turn, which also makes validation errors point at the right model.
NewType
A distinct type wrapping an existing one, used to give a plain value a name and a set of
constraints — Id, CountryCodeAlpha2, LanguageTag. At runtime the value is still a
str; the wrapper carries the validation rules and survives into the generated artifacts,
which is why it is preferred over a bare str with a Field constraint.
ModelKey
The key type returned by discover_models(). Carries the model's entry-point name, its
entry_point string, and its tags. Not a plain string, and not a tuple — code
that assumes either will break.
Tag
A string attached to a model during discovery, classifying it orthogonally to its name —
feature, or overture:theme=buildings. Tags are what the CLI's --tag / --filter /
--exclude options select on. They are produced by tag providers registered on the
overture.tag_providers entry-point group; third parties can register their own. Eight
tags exist today: feature, overture, and one overture:theme=* per theme. overture
marks a model built on Overture's feature model — it subclasses OvertureFeature — which
a third party's own type can also be; it is not a claim that the type belongs to the
Overture schema.
Spec
The target-independent description of a model produced by the codegen's extraction layer,
before any output format is chosen — RecordSpec for a model, UnionSpec for a
discriminated union, FieldSpec for a field, EnumSpec for an enum. Renderers consume
specs; they never touch Pydantic models directly. This split is what lets a new output
format be a new renderer rather than new extraction logic. See
Write a new codegen target.
Extra
An optional dependency group declared under [project.optional-dependencies] and
installed with bracket syntax (package[extra]) or uv sync --all-extras. Distinct from
"extra fields", which is what no_extra_fields forbids on a model.