Potential duplicate Prague macrohood divisions

Context

In the Overture Czech divisions release: 2026-08-19.0 we identified 34 Prague macrohood pairs where:

• one record is named Praha-X
• the counterpart is named X
• both records have identical Overture point geometry
• both represent Prague divisions
• 24 of the 34 pairs share the same Wikidata ID

The likely cause is that Overture is preserving two related OSM objects:

• an administrative Prague borough relation, usually with OSM local_type=borough
• a suburb/place node, usually with local_type=suburb

Among the confirmed pairs:

• 33 prefixed records are borough
• 1 prefixed record (Praha-Ďáblice) is also suburb
• all 34 unprefixed counterparts are suburb

The attached Parquet file contains both records for every pair.

cz_prague_divisions_duplicate.parquet.zip

Potential issue

These records appear to represent duplicate geographic divisions at the Overture division level. The different OSM types may be meaningful in the source data, but downstream consumers that need one geographic division per area cannot safely retain both records.

This creates issues such as:

• duplicate divisions in administrative hierarchies
• ambiguous place-to-division assignments
• duplicate search and display results
• duplicated macrohood counts
• inconsistent use of Praha-X versus X

Suggested consideration

Could Overture consider one of the following?

1. Conflate the records into one canonical division where geometry, hierarchy, and identity evidence agree.
2. Preserve both source objects but publish an explicit equivalence/conflation relationship.
3. Designate the administrative borough relation as canonical while retaining the suburb record as source provenance or an alternate representation.

If conflated, the canonical display name should probably be the unprefixed form (Troja, not Praha-Troja), while preserving:

• both OSM source record IDs
• both source OSM types
• the shared Wikidata ID where available
• the best available boundary geometry

Confirmed duplicate pairs

Excluded name collision

Praha-Újezd and Újezd were not included because they have different geometry, parent hierarchy, and Wikidata identity. They should not be conflated based on name alone.

Start by inspecting the attached cz_prague_divisions_duplicate.parquet file and compare the listed pairs' geometry, hierarchy, OSM types, and Wikidata IDs. The issue does not name source files or tests; work is done when a canonical or equivalence behavior is chosen, implemented, and the 34 pairs—including the excluded Újezd collision—are validated against that decision.