The place key that lets
datasets line up.

The simple idea

Most geographic data arrives in different shapes. One source may use countries, another uses counties, another uses ZIP-like areas, and another uses a storm track or alert polygon. loc_id is the shared place key that lets those sources meet on the same map.

The goal is not to make every dataset look identical. The goal is to know which places each dataset belongs to, how those places relate, and when two different geography systems overlap.

Cities and street addresses

You should be able to start with the place description a person actually has. A city search can resolve an official name or alias to a populated place, municipality, representative point, and containing loc_id chain wherever those country sources are available. City government boundaries, built-up urban areas, and metro regions stay distinct even when people use the same city name for all three.

For a street address, a geocoder first turns the submitted text into a source-attributed coordinate and address components. The point resolver then finds the administrative spine and any maintained postal, electoral, weather, or other overlapping geography. An address is therefore an input to resolution, not a new administrative level. See Geometry family definitions for the city roles and the distinction between definitions and current country coverage.

Use it in three steps

Start with a small sample. If DaedalMap can resolve the places in your rows, the same geography path can scale through MCP, API, or bulk conversion.

• Test: paste a few rows on Test your data and inspect the matched loc_ids.
• Scale: use MCP, API, or bulk tools when the full dataset needs the same resolution path.
• Join: connect the output to maintained packs, Research MCP, maps, reports, or your own workflow.

The geometry spine

The main structure is the administrative spine: a smooth parent-child chain from broad places to smaller places. It starts at admin_0 for countries, then moves down through states or provinces, counties or districts, tracts, block groups, blocks, and other country-specific levels where the source geometry exists.

In plain terms, the spine lets the system move from "the world" to "a country" to "a county" to "a neighborhood-scale area" without switching to a new geography model. Water uses the same coordinate system, but not a fake country hierarchy: named oceans, seas, lakes, and marine jurisdictions are their own maintained geometry families.

Land, water, and marine boundaries

Every map coordinate can be checked against several real boundaries. The physical surface first tells us whether it is land or water. Named water boundaries then identify an ocean, sea, gulf, strait, or lake where that geometry is maintained. Administrative areas describe land governance, while EEZs and other marine jurisdictions describe overlapping water governance. None of these layers has to pretend to be another.

• Physical surface: the global land/water edge, including inland water, answers the basic land-or-water question.
• Named water bodies: the five oceans, named seas, gulfs, straits, and maintained lakes are pure geographic shapes with their own ids.
• Administrative spine: countries through local areas describe the maintained parent-child geography on land.
• Marine jurisdictions: EEZs and country-water areas may overlap a sea or ocean, but do not redefine it.

This matters for hazards. A tsunami coordinate may describe an offshore origin, a coastal runup observation, or an inland water-displacement event. DaedalMap keeps the source coordinate unchanged and reports its direct geometry relationships instead of moving it or guessing a sea from the nearest country.

Admin spine examples

The names of the levels can change by country. The important part is that the relationship stays stable: bigger places contain smaller places, and the loc_id keeps that chain available.

Sibling layers

Not every useful geography fits neatly inside the admin spine. ZIP-like areas, tribal areas, watersheds, forests, parks, marine zones, and alert polygons may cross county or state lines. These are sibling layers: real geography families that sit alongside the admin spine instead of becoming fake admin levels.

Sibling layers matter because many practical questions start there. A person may know a ZIP code, an emergency manager may care about an alert polygon, a researcher may care about a watershed, and a marine dataset may care about an ocean basin. Those are valid places to start, even when they do not nest cleanly under one county or one state.

How sibling layers connect

DaedalMap connects sibling layers to the admin spine with overlap bridges. Instead of guessing from a name or a center point, the bridge measures how much one shape overlaps another.

A shaped sibling's id begins with its owning ISO country. Its administrative ancestry records physical-area precision using a scale profile calculated from that country's adopted spine and pinned to its fingerprint. Median areas at each spine level and geometric-midpoint thresholds make broad shapes shorter and smaller shapes longer. This is area only--not population or importance. Crossing smaller admin areas does not make a feature broader; greatest overlap selects one same-depth prefix and overlap bridges retain all crossings. An official source jurisdiction code is used before geometry; a center point or matching name cannot decide country or state ownership.

• ZIP-like area to tracts: a ZCTA can overlap several Census tracts, so the bridge returns the ranked overlap list.
• Tribal area to counties: a tribal area can cross county or state boundaries, so it is compared by measured area overlap.
• Watershed to admin areas: a watershed can be treated as its own layer while still connecting back to counties or tracts for comparison.
• Water or marine region to countries: ocean and marine ids can sit beside the land spine while still linking back to relevant sovereign or territory ids where needed.
• Alert polygon to watch area: an Ops alert can be checked against the admin spine to explain which maintained places are affected.

Reading an id

On the admin spine, the number of segments is the level. USA-CA-037 has three segments, so it is admin_2. Drop the last segment to get the parent. Each level adds only its local code component; leading zeros are kept. For example, Canada's compact chain can end in CAN-BC-5931-021-0221-067 while its source metadata retains the complete Statistics Canada codes.

A shaped country sibling keeps the source code after an ISO3, area-depth ancestry, and family token--for example USA-CA-PLACE-0644000. Its segments describe area precision and identity, not a strict parent chain, so use the geometry tools rather than truncating it. Global source identifiers such as IHO1953-240001002 remain source aliases until a shaped canonical identity has reviewed country ownership.

Why this matters

loc_id turns location cleanup into a reusable data step. Explore can show the right boundary. Research can keep sources aligned to the same places. Ops can compare fresh alerts against maintained watch areas. Agents can query multiple packs and join the answers without cleaning up place names every time.

The core value is joinable geographic data. Once your rows have loc_id, they can meet the maintained pack layer and the tools built around it.

How people use it

Most users do not need to memorize ids. Start with a place name, a map click, an address, a coordinate, a ZIP-like input, or an event area. The system resolves that input onto the best available place layer, then uses loc_id behind the scenes to keep the result reusable.

• On a map: click a place and keep the returned id as the anchor for the next question.
• In chat: ask for a place by name; the system resolves it before querying the data.
• Across datasets: compare rows that share the same loc_id, or use a sibling bridge when the shapes overlap instead of matching exactly.
• In a report: keep the id beside the readable place name so the source trail remains clear.

Changing and disputed places

Geography moves. Counties merge, tracts are redrawn at each census, and national statistical agencies revise their layers on their own schedules. Each loc_id follows the source authority for that geography, and each level carries the vintage of the release it came from.

Levels can come from different releases. In Canada, the country, province, census division, and census subdivision layers come from the 2025 release, while dissemination areas and blocks come from 2021. A deep result reports what each level is built on rather than flattening them into one date.

Some boundaries are disputed. A loc_id answers which geography a row describes. Sovereignty, administration, and political recognition are separate questions, kept in separate fields. Taiwan, Kosovo, and Western Sahara each get their own coverage id so data about them stays addressable, and the id itself asserts no claim about who governs the area. The same rule applies to coordinates: DaedalMap reports the geometry a point actually falls in and never moves a source coordinate to make it fit.

Where the technical details live

This page explains the idea. The tool calls, request shapes, bridge fields, and converter guidance live in the technical docs.

• Geometry family definitions explains what administrative, postal, electoral, watershed, protected, weather, and other sibling systems mean.
• Geometry tools covers point lookup, boundaries, hierarchy calls, and sibling-layer bridges.
• Bring your data covers how a dataset should store geography before it enters the maintained pack layer.
• For agents covers how developers and agents call the same data layer.