You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Publish ranked OSM/Overture places globally with shared identity #399
OpenMapX should show useful destinations while people browse the map, including places that are missing from the basemap. An OSM/Overture match should behave as one place when tapped, searched for or opened in details. The result must fit the existing map style and remain practical to prepare, publish and serve on a global instance.
Current scope and status
Implementation is in PR #436, with final review revision 4b2275acc01eb4f763a8bff2b7353a75ed57e37a. This issue now covers global snapshot preparation and ambient place publication, alongside Germany and bounded custom regions worldwide. It supersedes the original one-region pilot scope and its exclusion of planet preparation.
Map product and identity
Ranked, named OSM and Overture destinations appear during ordinary browsing, using the map's native POI symbols, multilingual labels and conservative zoom/collision policy.
Accepted conflation links keep osm:<type>/<id> primary with GERS as an alias; Overture-only places use overture:<GERS>. Tile selection, category/search results and details share those identities.
Known duplicate representations across the owned basemap, category/selection markers and ambient layer are reconciled. Distinct OSM entities, nearby branches and tenants retain separate identities; equal names alone do not prove duplication.
Source-backed closure, confidence, private-access and tenant rules control eligibility. OSM policy/location remain authoritative for linked places. Source coverage, snapshot dates and Overture release provenance are exposed without implying a complete or currently verified business directory.
Global preparation and publication
Prepare explicit planet OSM and Overture snapshots through the existing source workflows. The OSM format-2 snapshot retains all allowlisted named POIs, including records without search aliases. Planet Overture uses one validated Places release and conflates against the same pinned OSM PBF.
Bound application memory with source-ID pages, a file-backed osmium node index, configurable DuckDB memory/spill and disk-backed conflation workspaces. Oversized exact-assignment components fail closed rather than producing truncated or arbitrary matches.
Build planet generations in committed 2,000-row pages with durable checkpoints. Unpublished data stays hidden from tiles and GERS resolution; final partition attachment and active-generation selection are atomic.
Resume an interrupted candidate only when source and policy signatures still match, or explicitly discard it. Preserve the last good generation during failures, allow rollback, retain immutable tile URLs for their cache leases and drop expired planet partitions.
Support the existing regional/Germany storage through additive migration. Admin controls cover preparation requirements, progress, enable/disable, rollback and planet resume/discard.
Serving and deployment decision
The implemented serving path is bounded PostGIS MVT behind the API. Regional PMTiles and Martin/PostGIS were compared; a generation-aware global PMTiles exporter is an alternative outside this implementation.
Supported setups use one authoritative PostGIS database: either colocated services or a dedicated preparation host, with multiple API origins and a CDN. Each origin retains zooms 13–18, at most 256 features/128 KiB per tile, a two-second SQL timeout and eight pending tile reads. Successful generation-specific tiles are immutable for seven days; discovery and errors remain uncached. Both dateline buffers and Web Mercator latitude bounds are handled explicitly.
Versioned identity and tile contracts reconcile accepted OSM/GERS entities across browsing, selection, search and details.
Native POI styling, multilingual labels, conservative prominence and tenant policy, with dense/sparse regional QA and worldwide correctness fixtures.
Known base/category/ambient duplicates reconcile without merging explicitly different identities; excluded OSM counterparts are not resurrected as Overture gaps.
Coverage/release provenance, freshness checks and safe absent/invalid-source behavior; documented OSM-only fallback when Overture is uninitialized.
Explicit planet source preparation with bounded extraction/conflation settings and the existing regional quality corpus applied to planet imports.
Actual migrated PostGIS tests, portable tests, types, production/Docker/docs builds and independent final review. Genuine pre-PR screenshots and clearly labeled later operator comparisons are attached to the PR.
Verification and deployment qualification
Final review of 4b2275acc01eb4f763a8bff2b7353a75ed57e37a integrated current main and resolved two identity defects: numeric basemap IDs cannot fall through to a nearby different entity, and category fusion cannot reassign an accepted canonical OSM identity through a conflicting link or spatial match. Blank optional resource settings now use their documented defaults. The independent final review found no remaining code blocker. Local verification passed 17,510 portable tests, 53 focused PostgreSQL/related tests, all 29 workspace type checks, the three production builds and documentation checks. All five required checks and every relevant remote CI job passed on 4b2275acc01eb4f763a8bff2b7353a75ed57e37a, including production migrations, database/backup/restore coverage, node/web/mobile tests, all affected production/Docker builds, docs, signatures, dependency review and CodeQL. PostgreSQL regressions exercise staged invisibility, multi-page recovery, backend termination, source changes, leases/rollback/discard, dateline buffers, Japanese labels and published bigint identities. The separate captured global fixture uses 10,001 synthetic places across five continents.
A full planet import and production global-load test were not run on the development machine. Fixture measurements are correctness/performance observations, not a planet hardware profile. Before rollout, operators must qualify source-tool memory, source/staging/index/WAL/retained-generation disk, cold and concurrent reads, CDN behavior, backup/replication recovery and representative local matching quality on their target infrastructure. Existing upstream numeric OSM-ID conversion paths are not covered by the published ambient string-ID guarantee.
#393 and #394 supplied the completed baseline/style groundwork. No issue dependency blocks the implemented snapshot-based path. #301 remains related work for incremental Overture release ingestion and broader planet operations; #303 covers a separate OSM replication lifecycle. This issue does not claim to implement their delta/replication contracts.
Independent publication databases, request-level replica routing, a global PMTiles/offline exporter, new AllThePlaces ingestion and a geocoder rewrite are outside scope. OpenConditions, adapters/feeds and mobility contracts are excluded.
Additional regional-landmark evidence from the discovery pilot
This belongs in #399's existing prominence/discovery scope; no separate landmark-discovery issue was created.
Follow-up live inspection on 2026-10-07 found Quirinus-Münster in Neuss present in the self-hosted OpenMapTiles source but absent from rendered POI labels. Camera: center [6.6916, 51.1982], zoom 15, bearing/pitch 0, viewport 430 × 932 CSS pixels, DPR 1, English, owned dark style. The source point [6.693227291107178, 51.19902166658045] is well within the viewport, so this is not the edge-clipping case tracked separately in #431.
Relevant source properties:
class: place_of_worship
subclass: christian
rank: 94
Names include name, name:latin, name_de, name_en, name_int; none of the language tags counted by the current notability expression were present.
Rechecked against main 3c80939d26a09f131b16d849895255436b5e5798:
The code therefore explains why the currently observed source feature is ineligible at zoom 15. The deployed application's revision and tile extract checksum remain unknown; the pilot is not a controlled before/after deployment comparison. See the #424 live pilot evidence.
Implication for this issue
A translated-name count is a useful international-notability heuristic, but can miss useful regional landmarks. Include this Neuss case alongside internationally prominent landmarks in the bounded prominence/rank design. Prefer auditable source-backed regional signals; do not invent popularity/review scores, hardcode this building, or reveal all churches globally.
Suggested additions to the verification corpus:
A source-present regional landmark with few translated names, such as Quirinus-Münster.
A source-present international landmark as a positive control.
Ordinary nearby places of worship as negative/crowding controls.
Dense and sparse scenes at zooms 14–18, with multilingual label and source/rendered eligibility evidence kept separate.
Shared identity and map-tap checks if the solution uses the ambient place layer rather than only basemap styling.
Keep the existing identity/tile-contract and rollout requirements. This evidence does not reduce the overall High effort of #399 or require an unplanned immediate pipeline. Search ranking (#428), nearby business identity preservation (#429), lexical retrieval (#430), and edge placement (#431) remain separate, independently reviewable work.
changed the title [-]Publish a ranked ambient OSM/Overture place layer with shared identity[/-][+]Publish ranked OSM/Overture places globally with shared identity[/+]on Oct 10, 2026
Problem and desired outcome
OpenMapX should show useful destinations while people browse the map, including places that are missing from the basemap. An OSM/Overture match should behave as one place when tapped, searched for or opened in details. The result must fit the existing map style and remain practical to prepare, publish and serve on a global instance.
Current scope and status
Implementation is in PR #436, with final review revision
4b2275acc01eb4f763a8bff2b7353a75ed57e37a. This issue now covers global snapshot preparation and ambient place publication, alongside Germany and bounded custom regions worldwide. It supersedes the original one-region pilot scope and its exclusion of planet preparation.Map product and identity
osm:<type>/<id>primary with GERS as an alias; Overture-only places useoverture:<GERS>. Tile selection, category/search results and details share those identities.Global preparation and publication
planetOSM and Overture snapshots through the existing source workflows. The OSM format-2 snapshot retains all allowlisted named POIs, including records without search aliases. Planet Overture uses one validated Places release and conflates against the same pinned OSM PBF.Serving and deployment decision
The implemented serving path is bounded PostGIS MVT behind the API. Regional PMTiles and Martin/PostGIS were compared; a generation-aware global PMTiles exporter is an alternative outside this implementation.
Supported setups use one authoritative PostGIS database: either colocated services or a dedicated preparation host, with multiple API origins and a CDN. Each origin retains zooms 13–18, at most 256 features/128 KiB per tile, a two-second SQL timeout and eight pending tile reads. Successful generation-specific tiles are immutable for seven days; discovery and errors remain uncached. Both dateline buffers and Web Mercator latitude bounds are handled explicitly.
Acceptance criteria implemented in PR #436
Verification and deployment qualification
Final review of
4b2275acc01eb4f763a8bff2b7353a75ed57e37aintegrated current main and resolved two identity defects: numeric basemap IDs cannot fall through to a nearby different entity, and category fusion cannot reassign an accepted canonical OSM identity through a conflicting link or spatial match. Blank optional resource settings now use their documented defaults. The independent final review found no remaining code blocker. Local verification passed 17,510 portable tests, 53 focused PostgreSQL/related tests, all 29 workspace type checks, the three production builds and documentation checks. All five required checks and every relevant remote CI job passed on4b2275acc01eb4f763a8bff2b7353a75ed57e37a, including production migrations, database/backup/restore coverage, node/web/mobile tests, all affected production/Docker builds, docs, signatures, dependency review and CodeQL. PostgreSQL regressions exercise staged invisibility, multi-page recovery, backend termination, source changes, leases/rollback/discard, dateline buffers, Japanese labels and published bigint identities. The separate captured global fixture uses 10,001 synthetic places across five continents.A full planet import and production global-load test were not run on the development machine. Fixture measurements are correctness/performance observations, not a planet hardware profile. Before rollout, operators must qualify source-tool memory, source/staging/index/WAL/retained-generation disk, cold and concurrent reads, CDN behavior, backup/replication recovery and representative local matching quality on their target infrastructure. Existing upstream numeric OSM-ID conversion paths are not covered by the published ambient string-ID guarantee.
Related work and boundaries
#393 and #394 supplied the completed baseline/style groundwork. No issue dependency blocks the implemented snapshot-based path. #301 remains related work for incremental Overture release ingestion and broader planet operations; #303 covers a separate OSM replication lifecycle. This issue does not claim to implement their delta/replication contracts.
Independent publication databases, request-level replica routing, a global PMTiles/offline exporter, new AllThePlaces ingestion and a geocoder rewrite are outside scope. OpenConditions, adapters/feeds and mobility contracts are excluded.