BRC-515: MAP Location Keys (quadkey, world, coordinates.*)

[rohenaz]

This pull request:

Proposes a new standard by creating a new markdown file in the appropriate directory and requests discussion and assignment of a BRC number.

Companion document: BRC-515 Companion — MAP Location Keys
Mechanism diagrams (quadkey encoding, prefix nesting, polar caps, custody vs position, multi-cell placement, portals, query semantics), the method and results of independently reproducing the §4 arithmetic, and the four remaining open items.

What this defines

MAP keys for placing things in — and across — worlds, so indexers can answer a region query and clients can render a map or globe.

Key	Rule
quadkey	Web Mercator quadkey, digits 0–3, length 1..30. List-valued — an object may occupy several cells. A valid quadkey is what places the output.
world	Optional world partition. Earth is the default and is expressed by omission. Ids must self-uniquify: genesis outpoint preferred, hex hash for off-chain worlds, myapp:<seed> a fallback.
coordinates.lat / .lng / .alt	Optional WGS 84 point, single-valued. MAP's established compound-attribute convention. Never places. The translation anchor.
geohash, h3	Optional non-placing read keys for consumers already indexing those systems, derived from the same point.

The BRC invents no OP_RETURN framing, no command set, and no ownership model. It rides MAP for attributes and 1Sat Ordinals for identity, custody and authorization.

Numbering

Filed as BRC-515, above every dependency: Bitcom 500, MAP 503, 1Sat 506, envelopes 507, and BRC-514 for state resolution.

Depends on PR #1 (the 500–513 corpus) and PR #4 (BRC-514) landing first or alongside, since both are cited normatively.

Custody and position are separate

§5 keeps two layers apart that a location system built on an ownership system can easily collapse:

• Custody — origin, transfer under sat ordering, tip, burn — is BRC-159's, cited and not restated.
• Position — the cells in effect at the tip — is this BRC's. A transaction that re-declares quadkey relocates the object; a transfer on its own leaves it at the same coordinates under new ownership.

Only the party who can spend the tip can write new MAP data, so BRC-159's spend authority already gates every relocation. No signature scheme is defined here.

An earlier draft restated origin/tip/pairing/order with an index-based pairing rule that contradicted BRC-159's sat ordering. That machinery is gone.

Uses MAP's commands rather than inventing removal semantics

SET places · ADD adds a cell · DELETE drops a cell · REMOVE unplaces. Cites BRC-503 §3's ::: instruction-set separator.

Portals

world may change across a transfer. Because MAP state carries forward, a transfer writing only world leaves quadkey in effect and the object arrives at the same cell in a different world. The BRC-159 origin is untouched, so identity survives. One world at a time; arrival is not authorization.

Section 4 is verified

The cell math is unchanged and was reproduced from the specification text alone: MAX_LAT, all three test vectors, the published bounding box to six decimals, every row of the z → edge-length table, the polar-cap digit claim, and exact prefix nesting.

Known dependencies

• PR OPL protocol corpus: Bitcom, B, AIP, MAP, Sigma, Addressing, 1Sat series, BAP, Bitcoin Schema (500-513) #1 (500–513 corpus) — BRC-503 must exist to cite.
• opldotdev/MAP PR BRC-515: MAP Location Keys (quadkey, world, coordinates.*) #3 — master declares SET | DELETE only while v2 declares six commands with different meanings. This BRC targets v2.
• MAP state along a 1Sat chain is unwritten; §5 carries a dependency note. Implementations merge each revision in sequence order, last write wins.
• go-templates and 1sat-sdk MAP parsers declare a non-existent DEL command, implement SET only, ignore :::, and never populate list values. Separate PRs.

Upstream: a PR to bsv-blockchain/BRCs is intentionally deferred. This PR is against opldotdev/BRCs master only.