Investigate ordinary business name/address retrieval using the Berlin EDEKA case #430

Before you start

• I searched existing issues, including closed issues. Evaluate semantic vector recall over the POI corpus #297 covers semantic/vector recall and Measure the incremental value of a direct AllThePlaces extract #397 covers an AllThePlaces comparison; neither is this bounded lexical retrieval investigation.

Objective

Determine why ordinary business name/address searches fail to retrieve a verified nearby business, using EDEKA Moch at Grunerstraße 20 in Berlin as the initial case. Establish whether the limiting factor is upstream coverage, query interpretation, deployed local data, or the lack of a local lexical candidate path, then recommend a bounded next step.

The goal is to make named business search reliable using evidence from existing sources before adding another production data pipeline or a semantic-search engine.

Scope

Verified starting evidence

Checked on 2026-10-07, against relevant code on main 3c80939d26a09f131b16d849895255436b5e5798:

• The official EDEKA profile lists EDEKA Moch at Grunerstr. 20, 10179 Berlin.
• The public autocomplete query returns street/address candidates, without the named EDEKA tenant.
• Shorter queries such as EDEKA Alexa and EDEKA Grunerstraße return an EDEKA at Alexanderstraße 25. That is a different returned address; it has not been verified as the same tenant. A nearby same-brand result must not count automatically as successful retrieval.
• These are adapted OpenMapX API responses, not raw MapTiler payloads. The deployed application revision, source generations, provider configuration and cache state were not available in the public pilot.

The code exposes distinct limitations that warrant investigation:

1. MapTiler autocomplete maps its returned candidates; the observed response alone does not identify whether the original provider omitted the tenant.
2. OSM search terms cover aliases, codes and generated acronyms. Features without such terms are skipped. This is an intentionally specialized index, not a complete ordinary-name business index.
3. The Overture POI provider exposes category search, rather than a named-business text candidate method.
4. POI text search currently selects the first text-capable provider.
5. Overpass text search matches the escaped full query against a feature's name; it does not decompose a name-plus-address query.

Investigation boundaries

Use a small, versioned set of ordinary business queries, including short names, names plus addresses, nearby alternative branches, ambiguous brands and negative queries. Start in the existing German pilot regions. Inspect available OSM/Overture data with stable source IDs and actual addresses; report explicitly when deployed data cannot be inspected.

Keep raw-provider retrieval, adapter output, combined candidates, ranking and UI selection as separate evidence layers. Capture authorized raw-provider evidence with credentials redacted. A missing final row does not by itself prove a missing source feature.

If the desired business exists in an available dataset, describe and evaluate a bounded lexical candidate path through the existing search composition. If it is absent, document the source gap and the evidence needed for a source-enrichment pilot.

Outside this task: a production ingestion pipeline, embeddings/vector search, global rollout, broad search UI redesign, or changing production data.

Completion criteria

• Pin the application revision, enabled providers, relevant dataset generations and cache conditions for a reproducible pilot, or record specific unavailable metadata.
• Verify the EDEKA tenant identity/address; distinguish it from nearby same-brand candidates.
• Determine present/absent/unknown status in the inspected OSM and Overture datasets, with stable IDs and provenance.
• Compare raw upstream, adapted, combined and ranked results for the versioned query set; do not infer raw-provider behavior from adapter output.
• For data-present cases, evaluate a small lexical prototype or document a concrete candidate-integration design: query decomposition, identity/deduplication, source credits, closures, result limits, fallback and cold/warm latency budgets.
• For data-absent cases, document a source-coverage recommendation without assuming AllThePlaces contains the tenant.
• Publish a go/no-go report with retrieval quality, false-branch controls, operational costs and a narrowly scoped implementation follow-up if justified. No production feature is required to close this investigation.

Dependencies

No known hard prerequisite. Reuse the evaluation foundation from #409 / #424 and its live evidence comment. #428 and #429 address independently reproduced ranking/deduplication defects; keep those effects separate when measuring retrieval. Related: #297 (semantic recall), #399 (place identity/map discovery), #397 / #400 (conditional ATP evaluation/productionization). These are related work, not blockers or a requirement to add a new source.