Expand Pelias with optional address, GeoNames, and interpolation sources #300

What problem would this solve?

The self-hosted Pelias preset imports OpenStreetMap and Who's On First, but leaves several Pelias-supported sources unused. Address coverage and interpolation quality can therefore be much weaker in areas where OSM house numbers are sparse.

What would you like to be able to do?

Make additional Pelias sources modular and region-aware: OpenAddresses, GeoNames, generated street polylines, and US TIGER-backed address interpolation where applicable. Preserve a minimal OSM+WOF profile for smaller deployments.

Acceptance criteria

• Each optional source has a service/CLI manifest contract, version/checksum metadata, coverage rules, licensing notes, and capacity estimate.
• Region selection maps deterministically to source downloads and rejects unsupported combinations.
• OpenAddresses and GeoNames can be downloaded, prepared, and imported independently.
• Street polylines and the interpolation database are generated in the correct Pelias dependency order.
• TIGER interpolation is US-only and never silently enabled outside supported coverage.
• Builds for the expanded profiles are resumable, observable, atomic from the query service's perspective, and recoverable after failure. Preserve the existing whole-tree staging/failure isolation; verify the additional importers and runtime-consumer handoff rather than replacing that groundwork.
• Operators can choose minimal, address-enhanced, and full profiles with documented CPU/RAM/disk expectations.
• A multilingual regional evaluation compares baseline and enhanced address/name recall, precision, autocomplete, and reverse geocoding.
• Duplicate/conflicting records keep source provenance and follow a documented Pelias ranking policy.
• Integration, smoke, and upgrade tests cover each profile.
• Documentation states that incremental Pelias refresh is not included unless separately designed.

Alternatives or workarounds

OSM-only keeps operations small but leaves known address gaps. Enabling every importer unconditionally makes regional deployments too expensive and complicates licensing.

Additional context

Reported starting point

• Pelias, Elasticsearch, Placeholder, and PIP services are defined.
• integrations/geocoding-pelias/ supports forward, reverse, and autocomplete requests.
• packages/cli/src/lib/pelias-data.ts builds OSM and Who's On First inputs.
• Configuration declares interpolation/polyline paths, but the build does not generate/import OpenAddresses, GeoNames, TIGER interpolation, or street polylines.
• Pelias refreshes currently use a full rebuild contract.
• The CLI already builds the entire Pelias data tree, including the Elasticsearch index, in a sibling staging directory via withStagedBuildDir. It promotes that tree only after the build succeeds; a caught build failure removes staging and preserves the previous tree, and promotion errors attempt rollback. This is existing failure-safe groundwork, not a resumable optional-source pipeline or a guarantee of uninterrupted live queries.

Area

Geocoding, CLI data preparation, self-hosted services.

References

• packages/cli/src/lib/pelias-data.ts
• packages/cli/src/lib/build-staging.ts
• docs/docs/guides/geocoders.md
• https://github.com/pelias/pelias
• https://github.com/pelias/docker
• https://github.com/pelias/interpolation