[rijnb]

Why

The service did its own OpenStreetMap border lookups with a FlatGeobuf file, flatgeobuf and flatbush. The same lookups now live in the mapcode-ts-borders package, so this service uses that package and deletes its own copy.

What changed

• Border lookups, mapcode ranking and the recording country now come from mapcode-ts-borders 1.0.0. BoundaryService, flatgeobuf and flatbush are removed.
• The service always uses the border data in the package (OpenStreetMap, May 2026) and logs the snapshot at startup. MAPCODE_BORDERS_PATH is no longer used, and the 4 data/*.fgb files are removed.
• The test fixture now uses real territory codes, because the package rejects unknown codes. The version is 2.12.0.

Scope

• Covers the service, its tests and the docs.
• API responses do not change.
• New border data comes with a new mapcode-ts-borders release and a dependency bump.

Blast Radius

Deployments need no config change. A MAPCODE_BORDERS_PATH that is still set is ignored, so it can be removed at any time.

Verification

• npm test passes 746 tests. Only 2 expectations changed, both for renamed fixture codes.
• Main and this branch gave byte-identical responses for 140,000 handler calls: 20,000 points, half of them near border vertices, with default, include, local, mapcodes, country and territory variants, plus the territories endpoint.
• npm run start with a .env that still sets MAPCODE_BORDERS_PATH=./data/borders.fgb starts, logs borders: OpenStreetMap 2026-05 and answers requests.

🤖 Generated with Claude Code