@mailwoman/resolver-wof-sqlite 2.1.0

package/README.md

@@ -0,0 +1,250 @@
+# @mailwoman/resolver-wof-sqlite
+
+FTS5-backed [Who's On First](https://whosonfirst.org/) SQLite resolver for [mailwoman](https://www.npmjs.com/package/mailwoman). Takes free-text place queries (`"Paris, FR"`, `"Springfield, IL"`) and returns ranked candidate place IDs + coordinates from a WOF SQLite distribution on disk.
+
+Phase 4.2 of the mailwoman neural-resolver plan — see [`docs/plan/phases/PHASE_4_2_wof_sqlite.md`](https://github.com/sister-software/mailwoman/blob/main/docs/plan/phases/PHASE_4_2_wof_sqlite.md) in the source repo.
+
+## Installation
+
+```bash
+npm install @mailwoman/resolver-wof-sqlite
+```
+
+Requires Node 22+ for built-in `node:sqlite`.
+
+## Quick start
+
+```ts
+import { WofSqlitePlaceLookup } from "@mailwoman/resolver-wof-sqlite"
+
+const lookup = new WofSqlitePlaceLookup({
+	databasePath: "/path/to/whosonfirst-data-admin-us-latest.db",
+	buildFts: true, // build the FTS5 index on first open (one-time cost)
+})
+
+const candidates = await lookup.findPlace({
+	text: "Springfield",
+	placetype: "locality",
+	country: "US",
+})
+
+for (const c of candidates) {
+	console.log(c.id, c.name, c.country, c.lat, c.lon, "score:", c.score)
+}
+
+lookup.close()
+```
+
+## Multi-shard (admin + postcode in one connection)
+
+Pass an array of paths to open multiple WOF shards on a single connection — each is opened as a
+separate SQLite schema via `ATTACH DATABASE`. Schema names auto-derive from filenames
+(`whosonfirst-data-admin-us-latest.db` → `admin_us`, `whosonfirst-data-postalcode-us-latest.db` →
+`postalcode_us`). Queries route by `placetype` — a `postalcode` query goes to the
+`postalcode_us` shard automatically, everything else hits main.
+
+```ts
+const lookup = new WofSqlitePlaceLookup({
+	databasePath: ["/data/wof/whosonfirst-data-admin-us-latest.db", "/data/wof/whosonfirst-data-postalcode-us-latest.db"],
+})
+
+await lookup.findPlace({ text: "Springfield", placetype: "locality" }) // → admin shard
+await lookup.findPlace({ text: "62701", placetype: "postalcode" }) // → postcode shard
+```
+
+Override schema names or routing explicitly when needed:
+
+```ts
+new WofSqlitePlaceLookup({
+	databasePath: ["/data/wof/admin.db", { path: "/data/oddly-named.db", schemaName: "pc", placetypes: ["postalcode"] }],
+})
+```
+
+Cross-shard `UNION` queries are not supported in one `findPlace` call — BM25 scores aren't
+comparable across separately-indexed corpora. Issue two `findPlace` calls and merge in your
+caller if you need that.
+
+## Getting the WOF SQLite distribution
+
+The Geocode Earth team mirrors WOF SQLite distributions at <https://data.geocode.earth/wof/dist/sqlite/>. The two relevant shards for v1:
+
+| Distribution                                   | Size (bz2) | Use                                                               |
+| ---------------------------------------------- | ---------- | ----------------------------------------------------------------- |
+| `whosonfirst-data-admin-us-latest.db.bz2`      | ~845 MB    | US administrative places (country / region / locality / borough). |
+| `whosonfirst-data-postalcode-us-latest.db.bz2` | ~320 MB    | US postcodes.                                                     |
+
+```bash
+curl -L -o whosonfirst-data-admin-us-latest.db.bz2 \
+  https://data.geocode.earth/wof/dist/sqlite/whosonfirst-data-admin-us-latest.db.bz2
+bunzip2 whosonfirst-data-admin-us-latest.db.bz2
+```
+
+## FTS5 index
+
+Upstream WOF SQLite distributions ship a `places` table but **not** an FTS5 index. The resolver needs FTS5 to do fast prefix + token-bag matching. Two options:
+
+1. **`buildFts: true` on construction** — builds the index lazily on first open. Cost is one-time but expensive (~minutes on the full US admin shard). Use for prototyping.
+2. **Pre-build the index with `mailwoman-wof-build-fts`** — ship the DB with the index included so first-open is fast. Recommended for production.
+
+### `mailwoman-wof-build-fts` CLI
+
+A one-shot operator script ships with this package as a `bin`:
+
+```bash
+npx mailwoman-wof-build-fts /path/to/whosonfirst-data-admin-us-latest.db
+```
+
+The CLI:
+
+- Opens the DB read-write.
+- Creates the `place_search` FTS5 virtual table (with the same schema the lazy build uses).
+- Populates it from `spr` + `names` (alternate-name concatenation included).
+- Builds the `place_bbox` R*Tree virtual table from `spr.min\_*`/`spr.max\_\*` columns for the
+  proximity + bbox query support.
+- Reports progress to stderr per phase (`checking` → `creating` → `populating` → `creating-bbox`
+  → `populating-bbox` → `done`).
+- Exits 0 with a no-op message if both indexes already exist.
+
+```bash
+# Refresh after pulling a newer WOF dump
+npx mailwoman-wof-build-fts /path/to/wof.db --drop
+```
+
+`--drop` rebuilds from scratch — useful after refreshing the `places` / `names` tables from a newer dump. Without `--drop` the CLI is a no-op when the index is already present.
+
+### `mailwoman-wof-build-slim` CLI
+
+Builds a trimmed WOF SQLite distribution sized for browser-side deployments (Path B of the demo plan). The full admin-US distribution is ~4 GB; a slim US bundle with the top-1k localities by population plus all postcodes lands at **~35 MB** — small enough to ship as a static asset.
+
+```bash
+# Defaults: --top 1000 localities, --countries US, drops geojson after building aux tables
+npx mailwoman-wof-build-slim \
+  --in /path/to/whosonfirst-data-admin-us-latest.db \
+  --in /path/to/whosonfirst-data-postalcode-us-latest.db \
+  --out /path/to/wof-hot.db
+
+# Tinier — top 100 localities only
+npx mailwoman-wof-build-slim --in admin-us.db --out wof-tiny.db --top 100
+
+# Multi-country
+npx mailwoman-wof-build-slim --in admin-na.db --out wof-na.db --countries US,CA,MX
+```
+
+What survives in the slim DB:
+
+- All ancestor placetypes (`country`, `region`, `county`, `borough`, `macroregion`) in scope
+- Top-K localities by `wof:population`
+- All postcodes in scope
+- All `names` rows for the selected place IDs
+- Fresh `place_search` (FTS5), `place_bbox` (R\*Tree), `place_population` aux tables
+
+What gets dropped: the `geojson` table, which is build-time only — `lookup.ts` never reads it at query time, and it accounts for ~95% of the on-disk size. The `place_population` aux table consumes `wof:population` from geojson before we drop it.
+
+`WofSqlitePlaceLookup` opens the slim DB without any code change. Out-of-set queries (a locality not in the top-K) correctly return zero hits.
+
+You can also build the index programmatically via the package's `./fts` subpath:
+
+```ts
+import { DatabaseSync } from "node:sqlite"
+import { buildPlaceSearchFts } from "@mailwoman/resolver-wof-sqlite/fts"
+
+const db = new DatabaseSync("/path/to/wof.db")
+const { created, indexedRows, durationMs } = buildPlaceSearchFts(db, {
+	drop: false,
+	onProgress: (phase, detail) => console.log(phase, detail),
+})
+db.close()
+```
+
+## Ranking
+
+The resolver scores candidates by:
+
+1. SQLite FTS5 BM25 (negated so higher = better).
+2. - `placetypeMatchBoost` when the candidate's placetype matches the query filter.
+3. - `localityImplicitBoost` when no placetype filter is set and the candidate is a locality.
+4. - `countryMatchBoost` when the country filter matches.
+5. - `directChildBoost` / `descendantBoost` when `parentId` is set.
+6. - `proximityBoost / (1 + distanceKm / proximityScaleKm)` when `near: {lat, lon}` is set — decays
+     smoothly with distance from the user's position. At distance 0 the boost is full magnitude; at
+     `proximityScaleKm` (default 100 km) it's half.
+7. − `lengthPenaltyWeight` × excess-length penalty (favors short matches over long matches on short
+   queries).
+
+## Geographic filters (Phase 4.3.x)
+
+Two query options use the package-built R\*Tree index over WOF's bounding boxes:
+
+```ts
+// Proximity boost (no hard filter — distant candidates aren't dropped, just ranked lower)
+lookup.findPlace({
+	text: "Springfield",
+	placetype: "locality",
+	near: { lat: 39.78, lon: -89.65 },
+})
+
+// Proximity boost + hard filter — drop anything beyond 200 km
+lookup.findPlace({
+	text: "Springfield",
+	placetype: "locality",
+	near: { lat: 39.78, lon: -89.65, maxDistanceKm: 200 },
+})
+
+// Bbox hard filter — only return candidates whose bbox intersects the box
+lookup.findPlace({
+	text: "Springfield",
+	placetype: "locality",
+	bbox: { minLat: 37, maxLat: 42.5, minLon: -91.5, maxLon: -87.5 },
+})
+```
+
+When the R*Tree index isn't present (DBs built before this feature), the bbox-hard-filter is
+silently dropped to preserve backwards compatibility. The proximity boost still works without the
+R*Tree because it computes haversine distance against the centroid columns directly. Rebuild with
+`mailwoman-wof-build-fts --drop <path>` to gain the bbox index.
+
+All weights are configurable via the second ctor argument:
+
+```ts
+new WofSqlitePlaceLookup({ databasePath }, { countryMatchBoost: 0.5 })
+```
+
+Defaults are in `lookup.ts::DEFAULT_WEIGHTS`.
+
+## Query syntax
+
+`FindPlaceQuery.text` accepts free-text input — apostrophes / parens / accented characters / etc.
+are all stripped safely before going to FTS5. Per-token rules:
+
+- **Bare tokens** (`"Paris"`, `"62701"`) become FTS5 **phrase matches**: `"Paris"` matches places
+  named exactly "Paris", `"62701"` matches the postcode 62701 exactly.
+- **Trailing `*`** (`"627*"`, `"Pari*"`) becomes FTS5 **prefix syntax**: `627*` matches every
+  postcode starting with 627, `Pari*` matches Paris / Parishville / etc. The caller explicitly
+  signals "prefix"; bare tokens stay phrase-matched for safety.
+- **Multiple tokens** join with implicit AND: `"Pari* TX"` matches places whose name contains
+  both a `Pari*`-prefixed word AND the word `TX`.
+
+Example: `findPlace({ text: "902*", placetype: "postalcode" })` returns 90201, 90210, 90211, …
+matching the Los Angeles ZIP corridor.
+
+## Attribution (CC-BY 4.0)
+
+Who's On First data is licensed [CC-BY 4.0](https://creativecommons.org/licenses/by/4.0/). Downstream applications shipping resolved results from this package **must** carry an attribution notice — for example:
+
+> Place data via [Who's On First](https://whosonfirst.org/) © Mapzen + contributors, CC-BY 4.0.
+
+This package itself is AGPL-3.0; the WOF data it indexes is CC-BY 4.0. The two licenses are separate — your application must comply with both.
+
+## Integration tests
+
+`resolver-wof-sqlite/integration.test.ts` exercises the resolver against a real WOF SQLite distribution. The suite is **skipped** when no DB is present — set `MAILWOMAN_WOF_DB` to override the lookup path, otherwise it defaults to `/mnt/playpen/mailwoman-data/wof/whosonfirst-data-admin-us-latest.db` (the canonical lab location). CI runs against the fixture-only suites; operators with real WOF data locally get an extra layer of validation.
+
+Coverage includes: placetype filtering, country filtering, the empty-result case, FTS5 special-character sanitization, Japanese alt-name resolution, parent-constrained lookup, and a performance budget (`findPlace` < 250 ms against the 142 k-row US admin shard).
+
+## Concurrency model
+
+This package opens a single `node:sqlite` connection per `WofSqlitePlaceLookup` instance. SQLite is single-writer / many-reader; the Kysely wrapper around the connection serializes all queries through a mutex. For high-concurrency HTTP servers, instantiate one resolver per request handler or per pool slot — sharing a single instance across concurrent requests is fine (queries queue) but won't parallelize across cores.
+
+## License
+
+AGPL-3.0. WOF data: CC-BY 4.0 (see Attribution above).

package/out/address-point-interpolation.d.ts

@@ -0,0 +1,48 @@
+/**
+ * @copyright Sister Software
+ * @license AGPL-3.0
+ * @author Teffen Ellis, et al.
+ *
+ *   Address-point interpolation — "Method 2" of the resolution ladder (#483, Phase 1 of
+ *   `docs/articles/plan/2026-06-11-resolution-ladder.md`): when the exact address-point tier (#476)
+ *   misses a house number, bracket the number with REAL neighbor points on the same street from the
+ *   same #476 shard and interpolate linearly in house-number space between them. Real occupancy
+ *   replaces TIGER's uniform-spacing assumption — the dominant error term of the TIGER pilot's gate
+ *   miss; TIGER range interpolation (`StreetInterpolator`) demotes to the fallback for streets too
+ *   sparse to bracket.
+ *
+ *   Matching key is `street_key` — THE shared normalizer plus the route fold
+ *   (`canonicalizeRouteKey`), identical at build time (`scripts/build-address-point-shard.ts`) and
+ *   query time, by construction. Scope is postcode-first like the segment tier; a query without a
+ *   postcode goes straight to the fallback (which carries its own statewide-ambiguity abstention).
+ *
+ *   Bracketing contract:
+ *
+ *   - Neighbor candidates NEVER include the queried number itself (any unit/duplicate row of it) — in
+ *       production the exact tier would already have answered an on-file number, and in the eval
+ *       this is what makes grading against the same shard non-circular by construction.
+ *   - Both-sided bracket (`bracket: "both"`): linear interpolation between the nearest known number
+ *       below and above; `uncertaintyM` = half the distance between them.
+ *   - Single-sided (`bracket: "single"`): linear extrapolation along the two nearest known numbers on
+ *       that side, capped at one pair-span beyond the nearest point (`t ≤ 2` — beyond that the line
+ *       carries no evidence and the query falls through); `uncertaintyM` = the pair distance plus
+ *       the extrapolated overshoot, explicitly larger than the both-sided radius.
+ *   - No bracket (no neighbors, a single known number, or past the extrapolation cap): fall through to
+ *       the TIGER fallback when configured, else null.
+ *
+ *   Standalone like the segment tier — core wiring rides the Phase 2 ordered `spatialTiers` list.
+ */
+import { DatabaseSync } from "node:sqlite";
+import type { InterpolationLookup } from "@mailwoman/resolver";
+import type { InterpolatedHit, InterpolationQuery, StreetInterpolator } from "./interpolation.js";
+export declare class AddressPointInterpolator implements InterpolationLookup {
+    #private;
+    constructor(opts: {
+        dbPath?: string;
+        database?: DatabaseSync;
+        fallback?: StreetInterpolator;
+    });
+    find(query: InterpolationQuery): InterpolatedHit | null;
+    close(): void;
+}
+//# sourceMappingURL=address-point-interpolation.d.ts.map

package/out/address-point-interpolation.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"address-point-interpolation.d.ts","sourceRoot":"","sources":["../address-point-interpolation.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAiCG;AAEH,OAAO,EAAE,YAAY,EAAE,MAAM,aAAa,CAAA;AAE1C,OAAO,KAAK,EAAE,mBAAmB,EAAE,MAAM,qBAAqB,CAAA;AAG9D,OAAO,KAAK,EAAE,eAAe,EAAE,kBAAkB,EAAE,kBAAkB,EAAE,MAAM,oBAAoB,CAAA;AA2BjG,qBAAa,wBAAyB,YAAW,mBAAmB;;gBAMvD,IAAI,EAAE;QAAE,MAAM,CAAC,EAAE,MAAM,CAAC;QAAC,QAAQ,CAAC,EAAE,YAAY,CAAC;QAAC,QAAQ,CAAC,EAAE,kBAAkB,CAAA;KAAE;IA0B7F,IAAI,CAAC,KAAK,EAAE,kBAAkB,GAAG,eAAe,GAAG,IAAI;IAcvD,KAAK,IAAI,IAAI;CAGb"}

package/out/address-point-interpolation.js

@@ -0,0 +1,164 @@
+/**
+ * @copyright Sister Software
+ * @license AGPL-3.0
+ * @author Teffen Ellis, et al.
+ *
+ *   Address-point interpolation — "Method 2" of the resolution ladder (#483, Phase 1 of
+ *   `docs/articles/plan/2026-06-11-resolution-ladder.md`): when the exact address-point tier (#476)
+ *   misses a house number, bracket the number with REAL neighbor points on the same street from the
+ *   same #476 shard and interpolate linearly in house-number space between them. Real occupancy
+ *   replaces TIGER's uniform-spacing assumption — the dominant error term of the TIGER pilot's gate
+ *   miss; TIGER range interpolation (`StreetInterpolator`) demotes to the fallback for streets too
+ *   sparse to bracket.
+ *
+ *   Matching key is `street_key` — THE shared normalizer plus the route fold
+ *   (`canonicalizeRouteKey`), identical at build time (`scripts/build-address-point-shard.ts`) and
+ *   query time, by construction. Scope is postcode-first like the segment tier; a query without a
+ *   postcode goes straight to the fallback (which carries its own statewide-ambiguity abstention).
+ *
+ *   Bracketing contract:
+ *
+ *   - Neighbor candidates NEVER include the queried number itself (any unit/duplicate row of it) — in
+ *       production the exact tier would already have answered an on-file number, and in the eval
+ *       this is what makes grading against the same shard non-circular by construction.
+ *   - Both-sided bracket (`bracket: "both"`): linear interpolation between the nearest known number
+ *       below and above; `uncertaintyM` = half the distance between them.
+ *   - Single-sided (`bracket: "single"`): linear extrapolation along the two nearest known numbers on
+ *       that side, capped at one pair-span beyond the nearest point (`t ≤ 2` — beyond that the line
+ *       carries no evidence and the query falls through); `uncertaintyM` = the pair distance plus
+ *       the extrapolated overshoot, explicitly larger than the both-sided radius.
+ *   - No bracket (no neighbors, a single known number, or past the extrapolation cap): fall through to
+ *       the TIGER fallback when configured, else null.
+ *
+ *   Standalone like the segment tier — core wiring rides the Phase 2 ordered `spatialTiers` list.
+ */
+import { DatabaseSync } from "node:sqlite";
+import { haversineKm } from "./geo.js";
+import { hasTable } from "./sqlite-utils.js";
+import { canonicalizeRouteKey, normalizeStreetForKey } from "./street-normalize.js";
+/**
+ * Extrapolation cap for a single-sided bracket: at most one pair-span beyond the nearest known
+ * point (`t = 2`). Past it, the two-point line carries no evidence about the query number.
+ */
+const MAX_EXTRAPOLATION_T = 2;
+export class AddressPointInterpolator {
+    #db;
+    #ownsDb;
+    #fallback;
+    #byPostcode;
+    constructor(opts) {
+        if (opts.database) {
+            this.#db = opts.database;
+            this.#ownsDb = false;
+        }
+        else if (opts.dbPath) {
+            this.#db = new DatabaseSync(opts.dbPath, { readOnly: true });
+            this.#ownsDb = true;
+        }
+        else {
+            throw new Error("AddressPointInterpolator: one of dbPath or database is required");
+        }
+        this.#fallback = opts.fallback;
+        // Degrade gracefully on an empty/tableless shard (#568): with no `address_point` table this tier
+        // is skipped, deferring to the segment fallback rather than crashing at construction.
+        if (hasTable(this.#db, "address_point")) {
+            // Strictly-numeric neighbor numbers on the route-folded street key within the ZIP. The
+            // queried number itself is excluded HERE (see module doc: non-circular by construction).
+            this.#byPostcode = this.#db.prepare(`SELECT CAST(number AS INTEGER) AS n, lat, lon, source, release
+				 FROM address_point
+				 WHERE postcode = ? AND street_key = ?
+					AND number GLOB '[0-9]*' AND number NOT GLOB '*[^0-9]*'
+					AND CAST(number AS INTEGER) != ?`);
+        }
+    }
+    find(query) {
+        const streetKey = canonicalizeRouteKey(normalizeStreetForKey(query.street));
+        const numberRaw = query.number.trim();
+        if (!streetKey || !/^\d+$/.test(numberRaw))
+            return null;
+        const n = Number(numberRaw);
+        // No own table (empty shard) or no postcode → defer to the segment fallback rather than query.
+        if (!this.#byPostcode || !query.postcode)
+            return this.#fallback?.find(query) ?? null;
+        const rows = this.#byPostcode.all(query.postcode.trim(), streetKey, n);
+        const hit = rows.length >= 2 ? interpolateFromNeighbors(rows, n) : null;
+        return hit ?? this.#fallback?.find(query) ?? null;
+    }
+    close() {
+        if (this.#ownsDb)
+            this.#db.close();
+    }
+}
+/** Collapse rows to one centroid anchor per distinct house number, sorted ascending. */
+function anchorsByNumber(rows) {
+    const byN = new Map();
+    for (const row of rows) {
+        const group = byN.get(row.n);
+        if (group)
+            group.push(row);
+        else
+            byN.set(row.n, [row]);
+    }
+    return [...byN.entries()]
+        .map(([n, group]) => ({
+        n,
+        lat: group.reduce((sum, r) => sum + r.lat, 0) / group.length,
+        lon: group.reduce((sum, r) => sum + r.lon, 0) / group.length,
+        source: group[0].source,
+        release: group[0].release,
+    }))
+        .sort((a, b) => a.n - b.n);
+}
+function interpolateFromNeighbors(rows, n) {
+    const anchors = anchorsByNumber(rows);
+    // Nearest known number below and above the query (the rows never contain n itself).
+    let below;
+    let above;
+    for (const anchor of anchors) {
+        if (anchor.n < n)
+            below = anchor;
+        else {
+            above = anchor;
+            break;
+        }
+    }
+    if (below && above) {
+        const t = (n - below.n) / (above.n - below.n);
+        const spanM = haversineKm(below.lat, below.lon, above.lat, above.lon) * 1000;
+        return {
+            lat: below.lat + (above.lat - below.lat) * t,
+            lon: below.lon + (above.lon - below.lon) * t,
+            interpolated: true,
+            method: "address_point",
+            bracket: "both",
+            uncertaintyM: Math.round(spanM / 2),
+            source: below.source,
+            release: below.release,
+        };
+    }
+    // Single-sided: extrapolate along the two nearest known numbers on the populated side.
+    // `near` is the anchor closest to n, `far` the next one out; t > 1 by construction.
+    const side = below ? anchors.slice(-2) : anchors.slice(0, 2);
+    if (side.length < 2)
+        return null;
+    const [far, near] = below ? [side[0], side[1]] : [side[1], side[0]];
+    const t = (n - far.n) / (near.n - far.n);
+    if (t > MAX_EXTRAPOLATION_T)
+        return null;
+    const lat = far.lat + (near.lat - far.lat) * t;
+    const lon = far.lon + (near.lon - far.lon) * t;
+    const pairM = haversineKm(near.lat, near.lon, far.lat, far.lon) * 1000;
+    const overshootM = haversineKm(lat, lon, near.lat, near.lon) * 1000;
+    return {
+        lat,
+        lon,
+        interpolated: true,
+        method: "address_point",
+        bracket: "single",
+        // Explicitly larger than the both-sided radius: the whole pair span plus the overshoot.
+        uncertaintyM: Math.round(pairM + overshootM),
+        source: near.source,
+        release: near.release,
+    };
+}
+//# sourceMappingURL=address-point-interpolation.js.map

package/out/address-point-interpolation.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"address-point-interpolation.js","sourceRoot":"","sources":["../address-point-interpolation.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAiCG;AAEH,OAAO,EAAE,YAAY,EAAE,MAAM,aAAa,CAAA;AAI1C,OAAO,EAAE,WAAW,EAAE,MAAM,UAAU,CAAA;AAEtC,OAAO,EAAE,QAAQ,EAAE,MAAM,mBAAmB,CAAA;AAC5C,OAAO,EAAE,oBAAoB,EAAE,qBAAqB,EAAE,MAAM,uBAAuB,CAAA;AAEnF;;;GAGG;AACH,MAAM,mBAAmB,GAAG,CAAC,CAAA;AAmB7B,MAAM,OAAO,wBAAwB;IAC3B,GAAG,CAAc;IACjB,OAAO,CAAS;IAChB,SAAS,CAAgC;IACzC,WAAW,CAAiD;IAErE,YAAY,IAAiF;QAC5F,IAAI,IAAI,CAAC,QAAQ,EAAE,CAAC;YACnB,IAAI,CAAC,GAAG,GAAG,IAAI,CAAC,QAAQ,CAAA;YACxB,IAAI,CAAC,OAAO,GAAG,KAAK,CAAA;QACrB,CAAC;aAAM,IAAI,IAAI,CAAC,MAAM,EAAE,CAAC;YACxB,IAAI,CAAC,GAAG,GAAG,IAAI,YAAY,CAAC,IAAI,CAAC,MAAM,EAAE,EAAE,QAAQ,EAAE,IAAI,EAAE,CAAC,CAAA;YAC5D,IAAI,CAAC,OAAO,GAAG,IAAI,CAAA;QACpB,CAAC;aAAM,CAAC;YACP,MAAM,IAAI,KAAK,CAAC,iEAAiE,CAAC,CAAA;QACnF,CAAC;QACD,IAAI,CAAC,SAAS,GAAG,IAAI,CAAC,QAAQ,CAAA;QAC9B,iGAAiG;QACjG,sFAAsF;QACtF,IAAI,QAAQ,CAAC,IAAI,CAAC,GAAG,EAAE,eAAe,CAAC,EAAE,CAAC;YACzC,uFAAuF;YACvF,yFAAyF;YACzF,IAAI,CAAC,WAAW,GAAG,IAAI,CAAC,GAAG,CAAC,OAAO,CAClC;;;;sCAIkC,CAClC,CAAA;QACF,CAAC;IACF,CAAC;IAED,IAAI,CAAC,KAAyB;QAC7B,MAAM,SAAS,GAAG,oBAAoB,CAAC,qBAAqB,CAAC,KAAK,CAAC,MAAM,CAAC,CAAC,CAAA;QAC3E,MAAM,SAAS,GAAG,KAAK,CAAC,MAAM,CAAC,IAAI,EAAE,CAAA;QACrC,IAAI,CAAC,SAAS,IAAI,CAAC,OAAO,CAAC,IAAI,CAAC,SAAS,CAAC;YAAE,OAAO,IAAI,CAAA;QACvD,MAAM,CAAC,GAAG,MAAM,CAAC,SAAS,CAAC,CAAA;QAE3B,+FAA+F;QAC/F,IAAI,CAAC,IAAI,CAAC,WAAW,IAAI,CAAC,KAAK,CAAC,QAAQ;YAAE,OAAO,IAAI,CAAC,SAAS,EAAE,IAAI,CAAC,KAAK,CAAC,IAAI,IAAI,CAAA;QAEpF,MAAM,IAAI,GAAG,IAAI,CAAC,WAAW,CAAC,GAAG,CAAC,KAAK,CAAC,QAAQ,CAAC,IAAI,EAAE,EAAE,SAAS,EAAE,CAAC,CAA0B,CAAA;QAC/F,MAAM,GAAG,GAAG,IAAI,CAAC,MAAM,IAAI,CAAC,CAAC,CAAC,CAAC,wBAAwB,CAAC,IAAI,EAAE,CAAC,CAAC,CAAC,CAAC,CAAC,IAAI,CAAA;QACvE,OAAO,GAAG,IAAI,IAAI,CAAC,SAAS,EAAE,IAAI,CAAC,KAAK,CAAC,IAAI,IAAI,CAAA;IAClD,CAAC;IAED,KAAK;QACJ,IAAI,IAAI,CAAC,OAAO;YAAE,IAAI,CAAC,GAAG,CAAC,KAAK,EAAE,CAAA;IACnC,CAAC;CACD;AAED,wFAAwF;AACxF,SAAS,eAAe,CAAC,IAAyB;IACjD,MAAM,GAAG,GAAG,IAAI,GAAG,EAAsB,CAAA;IACzC,KAAK,MAAM,GAAG,IAAI,IAAI,EAAE,CAAC;QACxB,MAAM,KAAK,GAAG,GAAG,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,CAAC,CAAA;QAC5B,IAAI,KAAK;YAAE,KAAK,CAAC,IAAI,CAAC,GAAG,CAAC,CAAA;;YACrB,GAAG,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,EAAE,CAAC,GAAG,CAAC,CAAC,CAAA;IAC3B,CAAC;IACD,OAAO,CAAC,GAAG,GAAG,CAAC,OAAO,EAAE,CAAC;SACvB,GAAG,CAAC,CAAC,CAAC,CAAC,EAAE,KAAK,CAAC,EAAE,EAAE,CAAC,CAAC;QACrB,CAAC;QACD,GAAG,EAAE,KAAK,CAAC,MAAM,CAAC,CAAC,GAAG,EAAE,CAAC,EAAE,EAAE,CAAC,GAAG,GAAG,CAAC,CAAC,GAAG,EAAE,CAAC,CAAC,GAAG,KAAK,CAAC,MAAM;QAC5D,GAAG,EAAE,KAAK,CAAC,MAAM,CAAC,CAAC,GAAG,EAAE,CAAC,EAAE,EAAE,CAAC,GAAG,GAAG,CAAC,CAAC,GAAG,EAAE,CAAC,CAAC,GAAG,KAAK,CAAC,MAAM;QAC5D,MAAM,EAAE,KAAK,CAAC,CAAC,CAAE,CAAC,MAAM;QACxB,OAAO,EAAE,KAAK,CAAC,CAAC,CAAE,CAAC,OAAO;KAC1B,CAAC,CAAC;SACF,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,CAAA;AAC5B,CAAC;AAED,SAAS,wBAAwB,CAAC,IAAyB,EAAE,CAAS;IACrE,MAAM,OAAO,GAAG,eAAe,CAAC,IAAI,CAAC,CAAA;IAErC,oFAAoF;IACpF,IAAI,KAA+B,CAAA;IACnC,IAAI,KAA+B,CAAA;IACnC,KAAK,MAAM,MAAM,IAAI,OAAO,EAAE,CAAC;QAC9B,IAAI,MAAM,CAAC,CAAC,GAAG,CAAC;YAAE,KAAK,GAAG,MAAM,CAAA;aAC3B,CAAC;YACL,KAAK,GAAG,MAAM,CAAA;YACd,MAAK;QACN,CAAC;IACF,CAAC;IAED,IAAI,KAAK,IAAI,KAAK,EAAE,CAAC;QACpB,MAAM,CAAC,GAAG,CAAC,CAAC,GAAG,KAAK,CAAC,CAAC,CAAC,GAAG,CAAC,KAAK,CAAC,CAAC,GAAG,KAAK,CAAC,CAAC,CAAC,CAAA;QAC7C,MAAM,KAAK,GAAG,WAAW,CAAC,KAAK,CAAC,GAAG,EAAE,KAAK,CAAC,GAAG,EAAE,KAAK,CAAC,GAAG,EAAE,KAAK,CAAC,GAAG,CAAC,GAAG,IAAI,CAAA;QAC5E,OAAO;YACN,GAAG,EAAE,KAAK,CAAC,GAAG,GAAG,CAAC,KAAK,CAAC,GAAG,GAAG,KAAK,CAAC,GAAG,CAAC,GAAG,CAAC;YAC5C,GAAG,EAAE,KAAK,CAAC,GAAG,GAAG,CAAC,KAAK,CAAC,GAAG,GAAG,KAAK,CAAC,GAAG,CAAC,GAAG,CAAC;YAC5C,YAAY,EAAE,IAAI;YAClB,MAAM,EAAE,eAAe;YACvB,OAAO,EAAE,MAAM;YACf,YAAY,EAAE,IAAI,CAAC,KAAK,CAAC,KAAK,GAAG,CAAC,CAAC;YACnC,MAAM,EAAE,KAAK,CAAC,MAAM;YACpB,OAAO,EAAE,KAAK,CAAC,OAAO;SACtB,CAAA;IACF,CAAC;IAED,uFAAuF;IACvF,oFAAoF;IACpF,MAAM,IAAI,GAAG,KAAK,CAAC,CAAC,CAAC,OAAO,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,OAAO,CAAC,KAAK,CAAC,CAAC,EAAE,CAAC,CAAC,CAAA;IAC5D,IAAI,IAAI,CAAC,MAAM,GAAG,CAAC;QAAE,OAAO,IAAI,CAAA;IAChC,MAAM,CAAC,GAAG,EAAE,IAAI,CAAC,GAAG,KAAK,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,CAAE,EAAE,IAAI,CAAC,CAAC,CAAE,CAAC,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,CAAE,EAAE,IAAI,CAAC,CAAC,CAAE,CAAC,CAAA;IACvE,MAAM,CAAC,GAAG,CAAC,CAAC,GAAG,GAAG,CAAC,CAAC,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC,GAAG,GAAG,CAAC,CAAC,CAAC,CAAA;IACxC,IAAI,CAAC,GAAG,mBAAmB;QAAE,OAAO,IAAI,CAAA;IAExC,MAAM,GAAG,GAAG,GAAG,CAAC,GAAG,GAAG,CAAC,IAAI,CAAC,GAAG,GAAG,GAAG,CAAC,GAAG,CAAC,GAAG,CAAC,CAAA;IAC9C,MAAM,GAAG,GAAG,GAAG,CAAC,GAAG,GAAG,CAAC,IAAI,CAAC,GAAG,GAAG,GAAG,CAAC,GAAG,CAAC,GAAG,CAAC,CAAA;IAC9C,MAAM,KAAK,GAAG,WAAW,CAAC,IAAI,CAAC,GAAG,EAAE,IAAI,CAAC,GAAG,EAAE,GAAG,CAAC,GAAG,EAAE,GAAG,CAAC,GAAG,CAAC,GAAG,IAAI,CAAA;IACtE,MAAM,UAAU,GAAG,WAAW,CAAC,GAAG,EAAE,GAAG,EAAE,IAAI,CAAC,GAAG,EAAE,IAAI,CAAC,GAAG,CAAC,GAAG,IAAI,CAAA;IACnE,OAAO;QACN,GAAG;QACH,GAAG;QACH,YAAY,EAAE,IAAI;QAClB,MAAM,EAAE,eAAe;QACvB,OAAO,EAAE,QAAQ;QACjB,wFAAwF;QACxF,YAAY,EAAE,IAAI,CAAC,KAAK,CAAC,KAAK,GAAG,UAAU,CAAC;QAC5C,MAAM,EAAE,IAAI,CAAC,MAAM;QACnB,OAAO,EAAE,IAAI,CAAC,OAAO;KACrB,CAAA;AACF,CAAC"}

package/out/address-point-schema.d.ts

@@ -0,0 +1,58 @@
+/**
+ * @copyright Sister Software
+ * @license AGPL-3.0
+ * @author Teffen Ellis, et al.
+ *
+ *   Typed schema for the SITUS / rooftop ADDRESS-POINT shards (`address-points-<cc>-<slug>.db`, built
+ *   by `scripts/build-address-point-shard.ts` — the #476/#567 national rooftop tier behind the
+ *   demo's "type any US address, get the building"). Single source of truth for the columns shared
+ *   by the BUILDER and the READER ({@link AddressPointSqliteLookup}), so a column rename in one is a
+ *   compile error in the other.
+ *
+ *   The builder's hot INSERT (tens of millions of rows per state) stays a POSITIONAL prepared
+ *   statement for throughput — but its column list is derived from {@link ADDRESS_POINT_COLUMNS}
+ *   here, and its table comes from {@link createAddressPointTable}, so the positional order can't
+ *   silently drift from what the reader expects. (Same convention as the candidate build: typed
+ *   schema guards the contract; positional inserts keep the speed.)
+ */
+import type { Kysely } from "kysely";
+/**
+ * One rooftop address point. `(street_norm, number)` within a `postcode` (preferred) or
+ * `locality_norm` scope is the lookup; `street_key` is the #483 route-fold key for interpolation.
+ * Coordinates are non-null (the builder drops non-finite coords). `unit`/`postcode`/`locality_norm`
+ * are nullable (not every source carries all three).
+ */
+export interface AddressPointTable {
+    /** Shared {@link normalizeStreetForKey} of the street — the build/query-consistent probe key. */
+    street_norm: string;
+    /** `canonicalizeRouteKey(street_norm)` — the route-fold key (#483 Method 2). */
+    street_key: string;
+    /** House number, normalized lower-case (kept TEXT — "123-A", "12 1/2" must survive). */
+    number: string;
+    unit: string | null;
+    postcode: string | null;
+    /** Shared {@link normalizeLocalityForKey} of the locality — the fallback scope. */
+    locality_norm: string | null;
+    /** The street as it appeared in the source (kept for display / debugging). */
+    street_raw: string;
+    lat: number;
+    lon: number;
+    /** Provenance: the dataset this point came from (e.g. `overture:us`, `openaddresses`). */
+    source: string;
+    /** The pinned data release the point was ingested from. */
+    release: string;
+}
+/** The address-point database schema for `new DatabaseClient<AddressPointDatabase>(...)`. */
+export interface AddressPointDatabase {
+    address_point: AddressPointTable;
+}
+/**
+ * The `address_point` columns in INSERT order. The builder's positional prepared statement derives
+ * its placeholder list from this, so the positional order can't drift from the DDL / the reader.
+ */
+export declare const ADDRESS_POINT_COLUMNS: readonly ["street_norm", "street_key", "number", "unit", "postcode", "locality_norm", "street_raw", "lat", "lon", "source", "release"];
+/** Create the `address_point` table — called before the streaming bulk load. */
+export declare function createAddressPointTable(db: Kysely<AddressPointDatabase>): Promise<void>;
+/** Create the three probe indexes the reader relies on (postcode-scope, locality-scope, route-key). */
+export declare function createAddressPointIndexes(db: Kysely<AddressPointDatabase>): Promise<void>;
+//# sourceMappingURL=address-point-schema.d.ts.map

package/out/address-point-schema.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"address-point-schema.d.ts","sourceRoot":"","sources":["../address-point-schema.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;GAgBG;AAEH,OAAO,KAAK,EAAE,MAAM,EAAE,MAAM,QAAQ,CAAA;AAEpC;;;;;GAKG;AACH,MAAM,WAAW,iBAAiB;IACjC,iGAAiG;IACjG,WAAW,EAAE,MAAM,CAAA;IACnB,gFAAgF;IAChF,UAAU,EAAE,MAAM,CAAA;IAClB,wFAAwF;IACxF,MAAM,EAAE,MAAM,CAAA;IACd,IAAI,EAAE,MAAM,GAAG,IAAI,CAAA;IACnB,QAAQ,EAAE,MAAM,GAAG,IAAI,CAAA;IACvB,mFAAmF;IACnF,aAAa,EAAE,MAAM,GAAG,IAAI,CAAA;IAC5B,8EAA8E;IAC9E,UAAU,EAAE,MAAM,CAAA;IAClB,GAAG,EAAE,MAAM,CAAA;IACX,GAAG,EAAE,MAAM,CAAA;IACX,0FAA0F;IAC1F,MAAM,EAAE,MAAM,CAAA;IACd,2DAA2D;IAC3D,OAAO,EAAE,MAAM,CAAA;CACf;AAED,6FAA6F;AAC7F,MAAM,WAAW,oBAAoB;IACpC,aAAa,EAAE,iBAAiB,CAAA;CAChC;AAED;;;GAGG;AACH,eAAO,MAAM,qBAAqB,wIAYxB,CAAA;AAEV,gFAAgF;AAChF,wBAAsB,uBAAuB,CAAC,EAAE,EAAE,MAAM,CAAC,oBAAoB,CAAC,GAAG,OAAO,CAAC,IAAI,CAAC,CAgB7F;AAED,uGAAuG;AACvG,wBAAsB,yBAAyB,CAAC,EAAE,EAAE,MAAM,CAAC,oBAAoB,CAAC,GAAG,OAAO,CAAC,IAAI,CAAC,CAY/F"}

package/out/address-point-schema.js

@@ -0,0 +1,67 @@
+/**
+ * @copyright Sister Software
+ * @license AGPL-3.0
+ * @author Teffen Ellis, et al.
+ *
+ *   Typed schema for the SITUS / rooftop ADDRESS-POINT shards (`address-points-<cc>-<slug>.db`, built
+ *   by `scripts/build-address-point-shard.ts` — the #476/#567 national rooftop tier behind the
+ *   demo's "type any US address, get the building"). Single source of truth for the columns shared
+ *   by the BUILDER and the READER ({@link AddressPointSqliteLookup}), so a column rename in one is a
+ *   compile error in the other.
+ *
+ *   The builder's hot INSERT (tens of millions of rows per state) stays a POSITIONAL prepared
+ *   statement for throughput — but its column list is derived from {@link ADDRESS_POINT_COLUMNS}
+ *   here, and its table comes from {@link createAddressPointTable}, so the positional order can't
+ *   silently drift from what the reader expects. (Same convention as the candidate build: typed
+ *   schema guards the contract; positional inserts keep the speed.)
+ */
+/**
+ * The `address_point` columns in INSERT order. The builder's positional prepared statement derives
+ * its placeholder list from this, so the positional order can't drift from the DDL / the reader.
+ */
+export const ADDRESS_POINT_COLUMNS = [
+    "street_norm",
+    "street_key",
+    "number",
+    "unit",
+    "postcode",
+    "locality_norm",
+    "street_raw",
+    "lat",
+    "lon",
+    "source",
+    "release",
+];
+/** Create the `address_point` table — called before the streaming bulk load. */
+export async function createAddressPointTable(db) {
+    await db.schema
+        .createTable("address_point")
+        .addColumn("street_norm", "text", (c) => c.notNull())
+        // `street_key` = canonicalizeRouteKey(street_norm): the route-fold key (#483 Method 2).
+        .addColumn("street_key", "text", (c) => c.notNull())
+        .addColumn("number", "text", (c) => c.notNull())
+        .addColumn("unit", "text")
+        .addColumn("postcode", "text")
+        .addColumn("locality_norm", "text")
+        .addColumn("street_raw", "text", (c) => c.notNull())
+        .addColumn("lat", "real", (c) => c.notNull())
+        .addColumn("lon", "real", (c) => c.notNull())
+        .addColumn("source", "text", (c) => c.notNull())
+        .addColumn("release", "text", (c) => c.notNull())
+        .execute();
+}
+/** Create the three probe indexes the reader relies on (postcode-scope, locality-scope, route-key). */
+export async function createAddressPointIndexes(db) {
+    await db.schema
+        .createIndex("idx_ap_postcode")
+        .on("address_point")
+        .columns(["postcode", "street_norm", "number"])
+        .execute();
+    await db.schema
+        .createIndex("idx_ap_locality")
+        .on("address_point")
+        .columns(["locality_norm", "street_norm", "number"])
+        .execute();
+    await db.schema.createIndex("idx_ap_streetkey").on("address_point").columns(["postcode", "street_key"]).execute();
+}
+//# sourceMappingURL=address-point-schema.js.map

package/out/address-point-schema.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"address-point-schema.js","sourceRoot":"","sources":["../address-point-schema.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;GAgBG;AAoCH;;;GAGG;AACH,MAAM,CAAC,MAAM,qBAAqB,GAAG;IACpC,aAAa;IACb,YAAY;IACZ,QAAQ;IACR,MAAM;IACN,UAAU;IACV,eAAe;IACf,YAAY;IACZ,KAAK;IACL,KAAK;IACL,QAAQ;IACR,SAAS;CACA,CAAA;AAEV,gFAAgF;AAChF,MAAM,CAAC,KAAK,UAAU,uBAAuB,CAAC,EAAgC;IAC7E,MAAM,EAAE,CAAC,MAAM;SACb,WAAW,CAAC,eAAe,CAAC;SAC5B,SAAS,CAAC,aAAa,EAAE,MAAM,EAAE,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,OAAO,EAAE,CAAC;QACrD,wFAAwF;SACvF,SAAS,CAAC,YAAY,EAAE,MAAM,EAAE,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,OAAO,EAAE,CAAC;SACnD,SAAS,CAAC,QAAQ,EAAE,MAAM,EAAE,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,OAAO,EAAE,CAAC;SAC/C,SAAS,CAAC,MAAM,EAAE,MAAM,CAAC;SACzB,SAAS,CAAC,UAAU,EAAE,MAAM,CAAC;SAC7B,SAAS,CAAC,eAAe,EAAE,MAAM,CAAC;SAClC,SAAS,CAAC,YAAY,EAAE,MAAM,EAAE,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,OAAO,EAAE,CAAC;SACnD,SAAS,CAAC,KAAK,EAAE,MAAM,EAAE,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,OAAO,EAAE,CAAC;SAC5C,SAAS,CAAC,KAAK,EAAE,MAAM,EAAE,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,OAAO,EAAE,CAAC;SAC5C,SAAS,CAAC,QAAQ,EAAE,MAAM,EAAE,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,OAAO,EAAE,CAAC;SAC/C,SAAS,CAAC,SAAS,EAAE,MAAM,EAAE,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,OAAO,EAAE,CAAC;SAChD,OAAO,EAAE,CAAA;AACZ,CAAC;AAED,uGAAuG;AACvG,MAAM,CAAC,KAAK,UAAU,yBAAyB,CAAC,EAAgC;IAC/E,MAAM,EAAE,CAAC,MAAM;SACb,WAAW,CAAC,iBAAiB,CAAC;SAC9B,EAAE,CAAC,eAAe,CAAC;SACnB,OAAO,CAAC,CAAC,UAAU,EAAE,aAAa,EAAE,QAAQ,CAAC,CAAC;SAC9C,OAAO,EAAE,CAAA;IACX,MAAM,EAAE,CAAC,MAAM;SACb,WAAW,CAAC,iBAAiB,CAAC;SAC9B,EAAE,CAAC,eAAe,CAAC;SACnB,OAAO,CAAC,CAAC,eAAe,EAAE,aAAa,EAAE,QAAQ,CAAC,CAAC;SACnD,OAAO,EAAE,CAAA;IACX,MAAM,EAAE,CAAC,MAAM,CAAC,WAAW,CAAC,kBAAkB,CAAC,CAAC,EAAE,CAAC,eAAe,CAAC,CAAC,OAAO,CAAC,CAAC,UAAU,EAAE,YAAY,CAAC,CAAC,CAAC,OAAO,EAAE,CAAA;AAClH,CAAC"}

package/out/address-point.d.ts

@@ -0,0 +1,29 @@
+/**
+ * @copyright Sister Software
+ * @license AGPL-3.0
+ * @author Teffen Ellis, et al.
+ *
+ *   SQLite implementation of core's `AddressPointLookup` (#476): exact `(street, number)` within a
+ *   postcode (preferred) or locality scope, against a per-state shard built by
+ *   `scripts/build-address-point-shard.ts`. Query-side normalization is THE shared normalizer
+ *   (`street-normalize.ts`) — identical to build-side, by construction.
+ *
+ *   Matching is exact-after-normalization only — no fuzzy street matching in this tier (measure how
+ *   far exact gets first; fuzz is a later, separate decision). Postcode scope is attempted first
+ *   (cheapest, most selective); locality scope is the fallback. Multiple hits (same number,
+ *   units/duplicates) return the first by rowid — coordinates of unit siblings are the same
+ *   building for tier purposes.
+ */
+import type { AddressPointHit, AddressPointLookup } from "@mailwoman/resolver";
+export declare class AddressPointSqliteLookup implements AddressPointLookup {
+    #private;
+    constructor(dbPath: string);
+    find(query: {
+        street: string;
+        number: string;
+        postcode?: string;
+        locality?: string;
+    }): AddressPointHit | null;
+    close(): void;
+}
+//# sourceMappingURL=address-point.d.ts.map

package/out/address-point.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"address-point.d.ts","sourceRoot":"","sources":["../address-point.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;GAeG;AAIH,OAAO,KAAK,EAAE,eAAe,EAAE,kBAAkB,EAAE,MAAM,qBAAqB,CAAA;AAmB9E,qBAAa,wBAAyB,YAAW,kBAAkB;;gBAKtD,MAAM,EAAE,MAAM;IAgB1B,IAAI,CAAC,KAAK,EAAE;QAAE,MAAM,EAAE,MAAM,CAAC;QAAC,MAAM,EAAE,MAAM,CAAC;QAAC,QAAQ,CAAC,EAAE,MAAM,CAAC;QAAC,QAAQ,CAAC,EAAE,MAAM,CAAA;KAAE,GAAG,eAAe,GAAG,IAAI;IAmB7G,KAAK,IAAI,IAAI;CAGb"}