Place
Coordinates, place names, admin codes, postal codes, and reference-system ids resolve to loc_id.
DaedalMap data starts as a table with places, times, and measurements.
loc_id connects each row to the maintained pack layer.
Clean rows work across maps, Research, Ops, and agent tools.
Coordinates, place names, admin codes, postal codes, and reference-system ids resolve to loc_id.
Time-aware rows use timestamp. Yearly filters work better when the table also stores year.
Measurements belong in numeric columns with readable names, units, source notes, and caveats.
Each row needs a place and one or more values. The place becomes loc_id. Static facts do
not need time fields; observations, events, and time series use timestamp and usually
year.
loc_id and at least one metric column.timestamp, year, units, and source notes.A source table often starts with ordinary coordinates and measurements.
site_name,latitude,longitude,timestamp,temperature_c
Site A,38.8462,-77.3064,2025-07-01,31.4
The resolved table keeps the original coordinates and adds the stable place identifier.
site_name,latitude,longitude,timestamp,year,loc_id,temperature_c
Site A,38.8462,-77.3064,2025-07-01,2025,USA-VA-059,31.4
Point lookup turns latitude and longitude into the deepest available loc_id plus the parent
chain above it. Use the deepest match for local observations, or roll up to a parent when the question
belongs at county, state, province, or country scale.
Reference lookup handles non-coordinate geography. Postal codes, admin identifiers, named places, warning zones, tribal areas, marine areas, and other catalog-backed systems resolve through DaedalMap reference bridges.
A maintained DaedalMap pack adds the trust layer around a clean table: metadata, source sheets, license and citation records, runtime files, QA checks, and release status.
loc_id, time fields, numeric metrics, and documented units.