Narrow place candidates without losing the real match
Spatial blocking makes place matching manageable, but can exclude the correct record. Separate candidate recall, name similarity and verified entity identity.
By 
Paul. Architecture and infrastructure
Location can make matching business records tractable by reducing the candidates worth comparing. It can also exclude the correct match before a sophisticated similarity model sees it. A useful linkage design therefore has two separate obligations: retain plausible true matches during candidate selection, then require enough evidence before asserting that two records identify the same place.
Drew Breunig's 27 September 2024 tutorial demonstrates place-data conflation using DuckDB, H3 and embeddings produced through Ollama. It joins Alameda County restaurant inspection data with Overture Places. This November 2026 retrospective draws a design argument from the example. The tutorial is the author's experiment, not an AL+ implementation or a transferable accuracy claim.
Decide which identity the join represents
A business name can identify a brand, a legal organization or one outlet. Those are different entities. Before choosing a threshold, define which one the application means. An inspection belongs to a physical establishment at a relevant time; attaching it to the nearest outlet of the same chain can produce a materially false statement.
The tutorial makes the problem concrete: exact names within an H3 cell can still connect different nearby chain locations. It also shows address differences caused by missing unit numbers. These cases have different meanings even though both appear as address disagreement. A policy that rejects every difference loses possible matches; one that accepts every familiar name can join the wrong establishment.
For a proposed supplier-directory integration, decide whether a match connects records of a location or records of the legal supplier. This example is a proposal, not a client dataset. A location key should not silently become authority to combine invoices, payment instructions or contractual obligations belonging to a separate legal entity.
Keep the identity decision visible in the output. “Likely the same outlet” is a narrower statement than “same company.” A downstream system should know which relation was asserted and what evidence supports it. Otherwise a cautious similarity result can become an unconditional business identity merely because it was written into a column called match.
Blocking defines what the matcher can recover
Spatial blocking groups records into candidate regions before comparing names or descriptions. Its computational attraction is straightforward: each record sees a local subset rather than the entire second dataset. The tutorial uses same-cell H3 candidates and explicitly recognizes cell-edge limitations. A true pair on opposite sides of a boundary can never win a comparison it does not enter.
The current H3 4.x traversal reference documents neighborhood operations such as gridDisk. That is present-day API evidence for exploring adjacent cells, not a claim that the tutorial executed a particular expansion. A neighborhood can help retain boundary candidates, but its grid distance is not a universal business-distance rule.
Choose expansion and distance checks from coordinate quality and the intended identity. A coarse geocode may place an establishment far from its actual entrance. A business may have moved. Missing coordinates can make the ordinary spatial route unavailable. Tighter cells reduce comparisons while potentially losing more relevant candidates; broader neighborhoods introduce more ambiguous outlets.
A proposed evaluation should inspect candidate recall separately: among known true pairs, how many survived blocking? Then measure the matching decision within those candidates. A high success rate on retained pairs can conceal a poor end-to-end result when the blocker excluded difficult records. Retain a separate route for uncertain or missing locations instead of treating them as confident nonmatches.
Similar meaning is weaker than identity
Embeddings can make related names and descriptions look similar even when their spelling differs. That is useful for candidate ranking. It can also make two unrelated establishments in the same business category look close. The vector score describes similarity under a representation, not verified identity or a calibrated probability that a merge is correct.
Add evidence appropriate to the relation. An address including its unit, a source-specific identifier or a verified contact can help distinguish nearby candidates. Such fields have their own limits: a shared website can represent an entire chain, while phone numbers and addresses can change. Preserve disagreements instead of hiding them behind one aggregate score.
Compare the best candidate with the next plausible candidate. A high top score can be unconvincing when another nearby outlet scores almost as highly. Do not require every record to have a match. Keeping an unresolved result is often preferable to manufacturing certainty so that a dashboard displays a higher completion percentage.
No threshold is proposed here as generally safe. A future implementation should use labeled examples representing its languages, location quality and business types. Include chain outlets, shared premises and moved establishments. These are suggested evaluation cases; no embeddings, database joins or matching experiments were run for this article.
False merges have asymmetric costs
A missed match leaves some integration work unfinished. A false merge can attach an adverse inspection result to the wrong business or send an operational update to the wrong record. The costs are different. An acceptable threshold depends on what happens after the link, rather than which method produces the most automatic matches.
For the proposed directory, publish a candidate relation first where uncertainty is material. Preserve both original identifiers, source dates, matching evidence and the decision revision. Let a review step confirm consequential links before dependent systems overwrite records. If a decision is corrected, identify which downstream outputs used it so the correction can propagate.
This approach costs review time and storage. The strongest counterargument is that low-stakes exploration may not need such machinery. A map used to inspect possible relationships can tolerate tentative matches if they remain visibly tentative. Stable shared identifiers may also make semantic matching unnecessary. Use the least complicated method that establishes the relation the application actually needs.
For business data integration, begin with the consequence of a false merge and the identity the join must establish. Then choose blocking rules that retain plausible pairs and evidence strong enough for the downstream action. A useful matching system can explain both why it joined two records and why it left another unresolved.