diff --git a/README.md b/README.md index 7e56cce5..1683a2fc 100644 --- a/README.md +++ b/README.md @@ -235,6 +235,7 @@ BRC | Standard 226 | [Miner-Enforced Resale-Royalty Covenant Tokens (OP_PUSH_TX)](./tokens/0226.md) 227 | [Frictionless On-Chain Onboarding via Pre-Funded Claimable Tokens](./apps/0227.md) 228 | [Unlinkable Payments under the Identity Paradigm](./payments/0228.md) +515 | [MAP Location Keys (quadkey, world, coordinates.*)](./apps/0515.md) ## License diff --git a/SUMMARY.md b/SUMMARY.md index 4cd46a51..95290343 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -20,6 +20,7 @@ * [NotaryHash — Privacy-Preserving Signed-Hash Notarization with SPV-Verifiable Certificates](./apps/0220.md) * [Block Media Format (BMF) — Composable On-Chain Audio/Video](./apps/0224.md) * [Frictionless On-Chain Onboarding via Pre-Funded Claimable Tokens](./apps/0227.md) +* [MAP Location Keys (quadkey, world, coordinates.*)](./apps/0515.md) ## Wallet diff --git a/apps/0515.md b/apps/0515.md new file mode 100644 index 00000000..06924b0e --- /dev/null +++ b/apps/0515.md @@ -0,0 +1,371 @@ +# BRC-515: MAP Location Keys (`quadkey`, `world`, `coordinates.*`) + +Luke Rohenaz (rohenaz@gmail.com) + +## Abstract + +This BRC defines MAP[1](#footnote-1) keys for placing things in — and across — worlds, so indexers can answer a region query and clients can render a map or globe. A location is one or more **Web Mercator quadtree cells** carried in the `quadkey` key. Parallel worlds (game seeds, simulations) are partitioned by the `world` key; Earth is the default and is expressed by omitting `world` entirely. One transaction MAY attach several identifiers to the same output so clients can join them (a URL on a place, a UPC on a shelf, a foreign txid on a pin). Indexers expose **prefix** and **viewport** queries; this document does not name a product. + +This BRC invents no `OP_RETURN` framing, no command set, and no ownership model. It rides the Magic Attribute Protocol (MAP) for attributes and 1Sat Ordinals[2](#footnote-2) for identity, custody and authorization. This document specifies only the keys, the cell encoding, the resulting spatial state, and the query predicates. + +## Motivation + +Maps, AR clients, and games all need the same primitive: *what is here?* "Here" may be a street corner on Earth or a plot in a seeded world that reuses Earth's coordinate system. Without a shared cell id, world id, and update rule, every app invents a private tag and no indexer can answer a region query for all of them. + +A cell id that subdivides a latitude/longitude rectangle spends equal bits on lon and lat. East–west metres per degree shrink as `cos(latitude)`, so those cells stay about the same height and become tall and skinny toward the poles. The same defect appears in a naive lat/lng quadtree. The Web Mercator tile pyramid avoids it: the ellipsoid is mapped to a square, then that square is quartered. Cells stay square in the projection (consistent aspect on the ground). Resolution gets finer toward the projection cutoff; the poles themselves are outside the square (about ±85.05°). + +This BRC therefore uses **one** cell encoding — a Bing-style **quadkey** over that pyramid — so a prefix is a parent cell, and a region query is a prefix (plus ancestor) lookup. + +3D models and other payloads are out of scope. Content MAY be attached to the same output by other protocols. + +## Specification + +The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are to be interpreted as described in RFC 2119[3](#footnote-3). + +### 1. MAP carriage + +The location keys are MAP keys. This BRC defines no commands of its own; it uses MAP's command set as specified in BRC-503[1](#footnote-1). + +Readers MUST scan an output's script for a MAP command: a data push of the ASCII Bitcom protocol id + +``` +1PuQa7K62MiKCtssSLKy1kh56WWU7MtUR5 +``` + +followed by a MAP command and its arguments. MAP MAY share the output with other protocols; when protocols are concatenated the separator is a push of the single byte `0x7c` (`|`), and multiple MAP commands in one output are joined by the `:::` instruction-set separator (BRC-503 §3) and evaluated in order. + +Inscriptions or other locking payload MAY precede `OP_RETURN` — one output can be, for example, a 1Sat lock plus this MAP data[7](#footnote-7). + +BRC-503 §1 frames MAP data in the `OP_FALSE OP_RETURN` data-carrier template of BRC-18, which makes the output unspendable. An object whose authorization model is spend authority (section 5) needs its output to stay spendable, because the spend is what carries it forward, so such an output MUST use a bare `OP_RETURN` after the lock instead. Indexers implementing BRC-503 MUST accept both framings. An object under a model that does not rely on spending — an identity signature, say — MAY use either. + +Illustrative shape (one output): + +``` + +OP_RETURN + 1PuQa7K62MiKCtssSLKy1kh56WWU7MtUR5 + SET + quadkey 032010110301120232 + coordinates.lat 40.6892 + coordinates.lng -74.0445 + url https://example.invalid/place +``` + +Unknown keys MUST be ignored by readers that do not implement them. Where MAP resolves a key's value at a point in an object's history, that resolution governs; this BRC adds no precedence rule of its own. + +No key prefix is reserved. The discriminator for `quadkey` is its value grammar (section 4.3): indexers MUST ignore, as a placement, any `quadkey` value that does not match it. + +### 2. Keys + +| Key | Value | Cardinality | Rule | +|-----|--------|-------------|------| +| `quadkey` | Web Mercator quadkey (section 4) | list | Each member is ASCII digits `0`–`3`, length 1..30. Presence of at least one valid value places the output. | +| `world` | World id (section 3) | single | MAY. Omit for Earth. | +| `coordinates.lat` | WGS 84 latitude, decimal degrees, ASCII | single | MAY. Both `coordinates.lat` and `coordinates.lng` or neither. | +| `coordinates.lng` | WGS 84 longitude, decimal degrees, ASCII | single | MAY. Both `coordinates.lat` and `coordinates.lng` or neither. | +| `coordinates.alt` | Altitude in metres above the WGS 84 ellipsoid, ASCII | single | MAY. Only with `coordinates.lat` and `coordinates.lng`. Never places. | +| `geohash` | Geohash of the same point, `^[0-9b-hjkmnp-z]{1,12}$` | single | MAY. Never places. | +| `h3` | H3 **cell** index of the same point, `^[0-9a-f]{15}$` | single | MAY. Never places. | + +The `coordinates.*` keys are MAP's established compound-attribute convention for geolocation and are not introduced here. Writers MUST NOT use bare `lat` or `lng` for these values. + +Presence of at least one valid `quadkey` value is the placement signal. Writers MAY also set MAP `app` or `type`; indexers MUST NOT require them. + +**Extent and position are different jobs.** `quadkey` carries the record's *extent* — the cells it occupies — and is therefore list-valued. `coordinates.*` carries its translatable *position* — a single anchor point — and never places the output. A record with many cells still has one point. `coordinates.*` MUST NOT be treated as a substitute cell id. + +`geohash` and `h3` follow the same pattern: redundant read keys for consumers already indexing those systems. They MAY appear only when `coordinates.*` is present, and MUST be derived from that same point. They never place the output and MUST NOT be treated as substitute cell ids. Section 4.9 explains why the systems do not substitute for one another. + +Every one of these keys is named for its encoding. Writers MUST NOT put one encoding's value under another's key: no quadkey in `geohash`, no geohash (or H3, or any other id) in `quadkey`, and **no H3 cell index in `geohash`** — an H3 index is not a geohash, and mislabeling it poisons every consumer that trusts the key name. + +Validation cannot catch this for you. The geohash alphabet is base-32 with `a`, `i`, `l` and `o` removed, and many H3 indexes are composed entirely of surviving characters — `8928308280fffff` satisfies the `geohash` grammar above while being an H3 index. Honest naming is therefore a normative rule rather than something a parser can enforce. + +#### 2.1 Placing, moving and unplacing + +These are MAP commands (BRC-503), not new operations: + +| Intent | Command | +|--------|---------| +| Place at one cell, replacing any cells in effect | `SET quadkey ` | +| Occupy an additional cell | `ADD quadkey ` | +| Give up one cell, keeping the rest | `SELECT DELETE quadkey ` | +| Unplace entirely (clears every cell at once) | `SELECT REMOVE quadkey` | + +In every command above, `` is the transaction carrying the record being edited. Whether a given transaction is allowed to edit that record is an **authorization** question, and this BRC does not answer it — section 5 does not define an ownership model, it requires that one exist. An indexer MUST NOT apply any of these commands unless the carrying transaction is authorized under the object's model. + +`CLEAR ` folds per BRC-514[10](#footnote-10) §5.6: it voids the writes of the named revision, not the whole record. Writers wanting to unplace SHOULD use `SELECT REMOVE quadkey`; erasing an object's entire MAP state requires naming every revision that wrote state. + +Writers SHOULD keep the cell list small, choosing a coarser `z` (section 4.7) in preference to enumerating many fine cells. Indexers MAY cap the number of cells they will index for one object and MUST document that cap. The cap MUST be at least 16. + +Any other MAP keys on the same command are **join tags**. A client that has one identifier can look up the others on that output. Key spellings for global identifiers are MAP's shared keyspace — BRC-503 §5 establishes `url`, `tx`, `topic`, `upc`, `isbn` and hash names such as `md5`; `name` follows BRC-160's MAP table. This BRC owns none of them and does not restate the list. + +### 3. Worlds + +A **world** is a partition of the cell space. The same cell in two worlds is not the same place. + +- **Earth is the default and is expressed by omission.** A writer placing on Earth SHOULD NOT emit `world` at all. `world` appears only when the record is *not* on this planet's default space. +- Any other world id is the exact UTF-8 bytes of the `world` push (case-sensitive), 1..128 bytes. + +World equality is those exact bytes. It never consults MAP's `app` key, so **a world id MUST carry its own uniqueness**. In order of preference: + +| Form | Use | +|------|-----| +| **Genesis outpoint** — the outpoint of an output that creates the world, in the `txid_vout` underscore form. The dot form is not a valid world id and indexers MUST NOT normalize it; world equality remains exact bytes. | Preferred. Unique with no coordination, and gives world metadata and world ownership somewhere to live without a registry. | +| **Hex hash** of the world's genesis parameters | For procedurally generated worlds with no on-chain presence. | +| `myapp:` | Fallback for hand-authored development worlds. Uniqueness depends on app authors choosing distinct prefixes. | + +A bare seed such as `seed-7` MUST NOT be used: with world equality defined on `world` alone, every unrelated application shipping the same string would silently share one world. + +Writers MUST NOT emit an empty `world`; for tolerance, indexers MUST accept an absent `world`, an empty `world`, and the lowercase ASCII string `earth` as the same (default) world (any other casing is an ordinary world id), and MUST NOT mix that world with any other id. + +If `app` and `world` disagree, `world` governs; `app` has no role in world identity. + +### 4. Cell encoding (Web Mercator quadkey) + +The cell space is the standard Web Mercator / slippy-map tile pyramid (EPSG:3857)[4](#footnote-4) over WGS 84[5](#footnote-5). The on-chain id is a **quadkey**[6](#footnote-6): the path from the root square to a tile, one digit per zoom level. + +#### 4.1 Projection limits + +``` +MAX_LAT = atan(sinh(π)) × 180/π + ≈ 85.0511287798 degrees +``` + +Longitude is the half-open interval `[-180, 180)`. Latitude outside `[-MAX_LAT, MAX_LAT]` is outside the projection. Writers MUST clip latitude to that range before encoding. Writers MUST reduce longitude with + +``` +λ ← ((λ + 180) mod 360) - 180 +``` + +so that `+180` becomes `-180`. + +**Polar caps.** The clip makes polar placement deterministic and coarse, not absent. Every point with `φ ≥ MAX_LAT` encodes to the northernmost tile row (`y = 0`; its quadkeys consist only of digits `0` and `1`); every point with `φ ≤ -MAX_LAT` encodes to the southernmost row (`y = n-1`; digits only `2` and `3`). Longitude still resolves within the cap, but all latitude detail poleward of the clip is flattened into that row. A writer placing polar content SHOULD therefore include `coordinates.lat` / `coordinates.lng` (section 4.9), which represents the poles exactly. + +#### 4.2 WGS 84 point → tile `(z, x, y)` + +`z` is the zoom (cell precision), an integer `1..30`. Let `n = 2^z`. + +``` +x = floor( (λ + 180) / 360 × n ) +y = floor( (1 − ln((1 + sin φ) / (1 − sin φ)) / (2π)) / 2 × n ) +``` + +`φ` is clipped latitude in radians; `λ` is reduced longitude in degrees. Then clamp: if `x = n` then `x = 0`; `y` MUST be clamped to `[0, n-1]`. + +`floor` assigns a point on an east or south tile edge to the eastern / southern neighbour. The north and west edges belong to the tile. + +`(z, x, y)` is the computational form. It is not written on chain. + +#### 4.3 Tile → quadkey + +``` +quadkey = "" +for i from z-1 down to 0: + digit = 0 + mask = 1 << i + if (x & mask) ≠ 0: digit += 1 + if (y & mask) ≠ 0: digit += 2 + append ASCII('0' + digit) to quadkey +``` + +Digits on the map (y grows south, as in web tiles): + +``` ++---+---+ +| 0 | 1 | ++---+---+ +| 2 | 3 | ++---+---+ +``` + +`len(quadkey) = z`. A `quadkey` value MUST match `^[0-3]{1,30}$`. Indexers MUST ignore an invalid `quadkey` as a placement. + +#### 4.4 Quadkey → tile + +``` +z = len(quadkey) +x = 0 +y = 0 +for i, ch in enumerate(quadkey): + bit = z - 1 - i + d = ch - '0' + if d & 1: x |= (1 << bit) + if d & 2: y |= (1 << bit) +``` + +#### 4.5 Tile → WGS 84 bbox + +``` +west = x / n × 360 - 180 +east = (x + 1) / n × 360 - 180 +north = atan(sinh(π × (1 - 2y / n))) × 180/π +south = atan(sinh(π × (1 - 2(y+1) / n))) × 180/π +``` + +A point lies in the unique tile produced by section 4.2. These bbox formulas are the inverse of that assignment. + +#### 4.6 Parents, children, prefixes + +| Relation | Rule | +|----------|------| +| Parent | Drop the last digit. The root (whole projected square) has no digit and is not written as a tag. | +| Children | Append `0`, `1`, `2`, or `3`. | +| Ancestor | `A` is an ancestor of `C` iff `A` is a prefix of `C`. | +| Prefix match | `C` matches prefix `P` iff `C = P` or `C` starts with `P`. | + +A prefix query for `P` returns tags at `P` and all finer cells inside it. + +#### 4.7 Choosing `z` + +`z` is a precision, not a map zoom the user happens to be looking at. Writers SHOULD pick a precision suited to the object and then name as many cells as it occupies (section 2.1): + +| `z` | Approx. equator edge | +|-----|----------------------| +| 10 | 39 km | +| 14 | 2.4 km | +| 16 | 611 m | +| 18 | 153 m | +| 20 | 38 m | +| 22 | 9.6 m | +| 24 | 2.4 m | + +Ground edge length scales as `cos(latitude)` times the equator figure (the cells stay square). Equator edge ≈ `40075016.69 / 2^z` metres. + +#### 4.8 Test vectors + +| lon | lat | z | x | y | `quadkey` | +|-----|-----|---|-----|-----|------------| +| -74.0445 | 40.6892 | 18 | 77154 | 98583 | `032010110301120232` | +| -74.0445 | 40.6892 | 16 | 19288 | 24645 | `0320101103011202` | +| 0 | 0 | 1 | 1 | 1 | `3` | + +The first row's bbox is approximately west −74.045105, south 40.688969, east −74.043732, north 40.690010. Parent of the z=18 cell is the z=16 cell shown. + +#### 4.9 Other geospatial systems: granularity and translation + +Other cell systems exist and are indexed by other consumers. They are different tessellations, not different spellings of the same thing: + +| System | Id form | Cell shape | Hierarchy | High latitudes | +|--------|---------|-----------|-----------|----------------| +| Web Mercator quadkey (this BRC) | base-4 string | square in projection, square-ish on ground | exact — parent is a string prefix | consistent aspect; clipped past ±85.05° | +| Geohash | base-32 string | lat/lng rectangle | exact — parent is a string prefix | tall-skinny cells; aspect alternates by length parity — even lengths are about twice as wide as tall | +| H3 cell index | 64-bit id (15-char hex) | hexagon (12 pentagons) on an icosahedron | approximate — a child hex is not exactly contained by its parent; ids are not plain string prefixes | uniform aspect; poles covered | +| Point (`coordinates.lat` / `coordinates.lng`) | decimal degrees | — | — | poles representable | + +The decisive properties, and what each system trades: + +| Property | Quadkey | Geohash | H3 | +|----------|---------|---------|-----| +| Exact nesting — parent is a string prefix, child fully contained, so a region query is a prefix match on a plain key-value index | yes | yes | no | +| Consistent cell aspect at high latitudes | yes | no | yes | +| Decodes directly to the web-map tile pyramid (`z/x/y`) every renderer already draws | yes | no | no | +| Poles addressable | caps collapse to the edge rows (section 4.1) — deterministic, coarse in latitude | yes, but cells degrade to ground slivers and the pole point is degenerate across longitudes | yes, with normal-sized cells | + +No candidate wins every row. This BRC takes exact nesting and renderer-native decoding, and pays for them at the polar caps; a record that must stay precise there carries the point. + +Translation rules: + +1. **Point → any cell is exact.** Every system defines point-to-cell at every resolution. A record that carries `coordinates.lat` / `coordinates.lng` can be indexed under any system, at any granularity, now or later. +2. **Cell → cell across systems is lossy.** The grids tessellate differently, so a cell in one system is covered by several partially-overlapping cells of another, and the covering varies with latitude. A cell id translated across systems MUST be treated as approximate. +3. **Cell → point recovers only the cell's center or bbox** — error up to the cell size (section 4.7). + +Therefore: **a writer that expects consumers on other geospatial systems SHOULD include `coordinates.lat` / `coordinates.lng`**, with enough decimal places for the intended precision (5 decimals ≈ 1.1 m of latitude; 6 ≈ 0.11 m). The quadkey carries the record's *extent*; the point carries its translatable *position*. A record published as a cell id alone — in any system — has permanently discarded everything finer than that cell. + +Approximate granularity equivalence at the equator (area-matched; geohash ground size is latitude-dependent and its even lengths are about twice as wide as tall): + +| Ground scale | quadkey `z` | geohash length | H3 resolution | +|--------------|-------------|----------------|---------------| +| ~5 km | 13 | 5 | 6–7 | +| ~1 km | 15–16 | 6 | 8 | +| ~150 m | 18 | 7 | 9–10 | +| ~40 m | 20 | 8 | 11 | +| ~5 m | 23 | 9 | 13 | + + +### 5. Objects, authorization and position + +A **placed object** is an output whose resolved MAP state carries at least one valid `quadkey`. + +Two separate questions follow, and this BRC answers only the second: + +| Question | Answered by | +|----------|-------------| +| Who may move this thing? | The object's **authorization model** — not this BRC | +| Where is it, and what does a query return? | **This BRC** | + +**Authorization is required, and is not defined here.** An indexer MUST NOT apply a position command unless the transaction carrying it is authorized to act on the target record. This BRC defines no ownership model and mandates none. It requires that one be in force, that the indexer state which one it enforces, and that commands it cannot authorize be ignored rather than applied. + +Two models are already available, and an application MAY use either: + +- **Spend authority (1Sat).** The object is a 1Sat token[2](#footnote-2). Its identity is the BRC-159 origin outpoint; it passes from holder to holder by BRC-159 transfer — a 1-satoshi input landing in a 1-satoshi output under sat ordering. Authority is simply the ability to spend the current tip, so a command carried by a transaction in the object's own chain is authorized and one carried by any other transaction is not. Burn, new-origin detection and tip resolution are BRC-159's, unchanged. +- **Identity signature.** The object need not be a token at all. A system that identifies users by signature — AIP[8](#footnote-8) or Sigma[9](#footnote-9), for instance — authorizes a command by verifying that the signature on the carrying transaction belongs to the party entitled to edit the target record. + +The point of the split is that a system using neither is still free to define its own. What it may not do is skip the question: MAP's `SELECT ` lets any transaction name any earlier one, so an indexer that applies position commands without an authorization check will let anyone move anyone else's object. + +**Position is this document's.** An object occupies the cells named by the `quadkey` values in effect at its **current record** — the most recent authorized write, which under spend authority is the tip of its 1Sat chain. A transaction that re-declares `quadkey` (section 2.1) **relocates** it. One that does not leaves it where it was, whoever now holds it. Removing `quadkey` unplaces it, and the object leaves the spatial index. + +Ownership and position advance independently. Under spend authority they share a chain but move at different rates: every relocation rides on a transfer, because writing MAP data means spending the output, yet most transfers relocate nothing. An indexer that treats a change of holder as a change of place has conflated the two layers. + +**Why this BRC needs no signature scheme of its own.** Both models above already bind a command to a party — one through the spend, the other through a signature — so adding a third would only compete with them. Indexers MUST NOT require a particular identity protocol. + +**Portals.** `world` MAY change on any authorized write. Because a write that sets only `world` leaves `quadkey` in effect, the object arrives at the same cell in a different world — a **portal**. A portal MAY also relocate the object by writing `quadkey` in the same command. The object's identity is unchanged throughout — under spend authority, the BRC-159 origin — so identity survives a portal. To return to the default world, clear the key with `SELECT REMOVE world`; `SET world earth` is honoured under section 3 but SHOULD NOT be written in preference to removal. + +An object occupies many cells but exactly one world at a time. + +A destination world receives whatever anyone able to spend a tip sends it; arrival is not an authorization. A world that restricts what it displays MUST filter on its own terms. + +**History.** An indexer MUST be able to emit the ordered list of `(outpoint, quadkey, world, join keys)` from origin to current record, and the unplace if any. This is a projection over the object's authorized writes, not a separate structure. + +Tags are claims, not proof of presence. Anyone MAY place a cell; only the current holder can relocate that object. + +**State resolution.** "In effect" means the result of folding the object's authorized writes as specified in BRC-514[10](#footnote-10). That document defines the revision order, the state model, and how each MAP command applies; this BRC adds nothing to it and defines no resolution rules of its own. + +### 6. Query + +This section is the predicate. It is not an HTTP API and not a particular indexer. + +Let `world(q)` be Earth when the query omits a world id or passes `earth`; otherwise the exact id. + +A stored record **matches world** iff its world equals `world(q)` under section 3. + +A record with several cells matches a query iff **any** of its cells matches. Indexers MUST return such a record once, not once per matching cell. + +**Prefix query.** Given `world` and prefix `P` (a quadkey, or empty `P` for the whole projection): every current record that matches the world and any of whose `quadkey` values prefix-matches `P` (section 4.6). + +**Viewport query.** Given `world` and a WGS 84 box `(west, south, east, north)`, with optional clip of `south`/`north` to `±MAX_LAT`: + +1. If the box crosses the antimeridian (`west > east`), split into `(west, south, 180, north)` and `(-180, south, east, north)` and union the results. +2. A record matches iff it matches the world **and** the bbox of at least one of its cells (section 4.5) **intersects** the (clipped, split) box. Intersection is closed: a shared edge counts as intersecting. `west = east` is a degenerate zero-width box, not a full wrap; the split in step 1 triggers only on `west > east`. + +Intersect includes descendants (finer tags inside the view), the covering cells, **and ancestors** (a coarse city-sized tag still appears when the view is a street). Empty `P` / a view of the whole projection returns every current record in that world. + +A sufficient algorithm for intersect using only prefix lookups: take the tiles at some zoom `z` that overlap the box; for each tile `T`, query prefix(`T`) and also the exact cells of every ancestor of `T`. Implementations MAY use any spatial index that returns the same set. + +Indexers MUST implement prefix and viewport as defined here. They MAY add filters (join key, time, origin). They MUST return at least: origin outpoint, current-record outpoint, every `quadkey` value in effect, world, remaining MAP keys in effect (the resolved state, section 5), txid, and confirmation height when mined. + +Three cases separate a conforming implementation from a plausible one, and SHOULD appear in any test suite: an ancestor tag coarser than the viewport (matches); a box crossing the antimeridian (splits and unions); and a point exactly on a tile's east or south edge (lands in the neighbour, per section 4.2). + +### 7. Out of scope + +- Content bytes (images, inscriptions, 3D models). Attach them with other protocols on the same output; this BRC does not read them. +- Geometry. `quadkey` names cells an object occupies; polylines, polygons and meshes are not expressible and are not intended to be. +- Alternate *placement* encodings. `geohash` and `h3` may ride along as non-placing read keys (sections 2, 4.9), but cross-system cell translation is lossy and placement is defined over `quadkey` only. +- Overlay wire formats, payment, or wallet baskets. + +## Implementations + +A compatible implementation tags outputs as in sections 1–5, answers section 6, and works for **Earth maps and seeded worlds** with the same cell math. + +Any client that already renders a Web Mercator map or globe can decode `quadkey` to `(z, x, y)` or a bbox and draw the record without a second projection. + +## References + +- 1: BRC-503 — *MAP — Magic Attribute Protocol*. Commands, the `:::` instruction-set separator, and the shared keyspace including the `coordinates.*` compound-attribute convention. +- 2: [BRC-159](../tokens/0159.md) — *1Sat Ordinals — Single-Satoshi Tokens and Origin Tracking*. Origin, sat ordering, transfer, tip and burn. +- 3: Bradner, S. (1997). *Key words for use in RFCs to Indicate Requirement Levels*. RFC 2119. https://www.rfc-editor.org/rfc/rfc2119 +- 4: IOGP. *WGS 84 / Pseudo-Mercator* — EPSG:3857. The well-known Web Mercator tile pyramid (slippy-map `z/x/y`). +- 5: NIMA. (2000). *Department of Defense World Geodetic System 1984*. TR8350.2. Horizontal positions in this BRC are WGS 84 (EPSG:4326) degrees. +- 6: Microsoft. *Bing Maps Tile System* — quadkey encoding of the Web Mercator pyramid. https://learn.microsoft.com/en-us/bingmaps/articles/bing-maps-tile-system +- 7: [BRC-160](../tokens/0160.md) — *1Sat Ordinals — Inscription Envelopes*. +- 8: BRC-502 — *AIP — Author Identity Protocol*. One available authorization model; not required by this BRC. +- 9: BRC-504 — *Sigma — Transaction-Bound Script Signatures*. One available authorization model; not required by this BRC. +- 10: BRC-514 — *MAP State Resolution over a 1Sat Chain*. Defines how a MAP key's value is resolved across a record's revisions. diff --git a/apps/README.md b/apps/README.md index fe5d588b..e2132ef9 100644 --- a/apps/README.md +++ b/apps/README.md @@ -14,3 +14,4 @@ BRC | Standard 220 | [NotaryHash — Privacy-Preserving Signed-Hash Notarization with SPV-Verifiable Certificates](./0220.md) 224 | [Block Media Format (BMF) — Composable On-Chain Audio/Video](./0224.md) 227 | [Frictionless On-Chain Onboarding via Pre-Funded Claimable Tokens](./0227.md) +515 | [MAP Location Keys (quadkey, world, coordinates.*)](./0515.md)