Skip to content

fix(domain-instances): OSM IDs are flat per-type spaces; adapter constructs prefix from coordinates #42

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
AdaWorldAPI merged 2 commits into from
Jun 5, 2026
Merged

fix(domain-instances): OSM IDs are flat per-type spaces; adapter constructs prefix from coordinates #42

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
06c15db
fix(domain-instances): OSM IDs are flat per-type spaces; adapter cons…
claude Jun 5, 2026
5b1fd22
fix(domain-instances): resolve Way / Relation geometry before derivin…
claude Jun 5, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 29 additions & 6 deletions docs/DOMAIN-INSTANCES.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -125,12 +125,35 @@ inner auth AND durable outer audit, and ships exactly that separation.

### 2.6 Geospatial / OSM — geographic calibration

**What OSM proves: geography doesn't break the IR.** OSM IDs are
*already* prefix-structured (`country/region/city/street/house`), so
the adapter is doing identity-*extraction*, not identity-construction
— a much smaller surface than typical. Three OSM Classes (`Node`,
`Way`, `Relation`) lift via the queued `ogar-from-osm-pbf` adapter
(`docs/RDF-OWL-ALIGNMENT.md §10` Phase 2c). Exercises:
**What OSM proves: geography doesn't break the IR.** OSM elements use
**per-element-type flat numeric ID spaces** ([OSM data model][osm-dm]
— `Node 100`, `Way 100`, and `Relation 100` are unrelated; IDs are
not hierarchical and carry no spatial information on their own). The
adapter therefore does identity *construction*, not extraction: it
computes the Cesium TMS quadkey from the element's **resolved**
geometry — only `Node`s carry coordinates directly; `Way`s and
`Relation`s reference other elements and must be resolved through
their members first:

- **`Node`** — quadkey from its own `lat`/`lon` (the only element
type that carries coordinates).
- **`Way`** — resolve the ordered `Node`-references first to get the
underlying lat/lon list, then take the centroid (or the smallest
covering tile at the target zoom — whichever fits the consumer's
query pattern).
- **`Relation`** — resolve member references recursively (members
are `Node`/`Way`/`Relation` refs with roles), then centroid /
covering tile, or an `admin_level`-boundary walk when the
Relation IS an administrative polygon.

The resolved quadkey gets prepended to the per-type OSM ID, yielding
the `NiblePath` form `osm/<quadkey>/<type>/<id>`. The quadkey IS the
spatial frame; the per-type ID is the leaf inside it. Three OSM
Classes (`Node`, `Way`, `Relation`) lift via the queued
`ogar-from-osm-pbf` adapter (`docs/RDF-OWL-ALIGNMENT.md §10` Phase
2c). Exercises:

[osm-dm]: https://wiki.openstreetmap.org/wiki/Data_model

- **Spatial prefix-locality** — Cesium TMS quadkey as `NiblePath`
prefix, per Q2 coordination outcome locked in `lance-graph` PR #473
Expand Down
Loading