OvertureMaps / OvertureMaps/data

[Places] Unrelated POIs collapsed onto bit-identical coordinates; the biggest piles sit on rounded ones

Open
#563 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
1.2k
Forks
47
Avg merge
3h 42m
Merged PRs (30d)
1

Description

I was looking at a map of central Tokyo and found businesses standing inside the
Imperial Palace grounds. A supermarket that belongs in Yurakucho Lumine, and a
musical instrument shop that belongs in Akihabara:

Places rendered inside the Imperial Palace grounds

They are not alone. Two points inside the palace carry 71 and 17 places, all at
one coordinate each, to the last bit:

71 places at 35.6833, 139.75

17 places at 35.6838011, 139.7539458

The first pin holds Imperial Hotel Tokyo and Otsuma Women's University. The
second holds a Yamanashi village office and a Shizuoka prefectural association.
61 of the 71 carry different street addresses, spread over nine city wards. The
addresses are largely correct. Only the geometry is gone.

Reproduce

Release 2026-08-19.0, DuckDB 1.3.2, about 80 seconds.

INSTALL httpfs; LOAD httpfs;
INSTALL spatial; LOAD spatial;
SET s3_region='us-west-2';

SELECT
  printf('%.7f', ST_Y(geometry)) || ',' || printf('%.7f', ST_X(geometry)) AS coord,
  count(*)                              AS places,
  count(DISTINCT addresses[1].freeform) AS distinct_street_addresses,
  count(DISTINCT names.primary)         AS distinct_names,
  round(max(confidence), 3)             AS max_confidence
FROM read_parquet(
  's3://overturemaps-us-west-2/release/2026-08-19.0/theme=places/type=place/*.parquet',
  hive_partitioning = 1
)
WHERE bbox.xmin BETWEEN 139.749 AND 139.755
  AND bbox.ymin BETWEEN 35.682  AND 35.685
GROUP BY 1
HAVING count(*) >= 5
ORDER BY places DESC;
                 coord  places  distinct_street_addresses  distinct_names  max_confidence
35.6833000,139.7500000      71                         61              71           0.987
35.6838011,139.7539458      17                         14              17           0.979

This is not local

Over the Japan bounding box (129-146E, 30-46N), 756 coordinates carry 10 or
more places each, 21,355 places in total, 0.74% of the 2,866,662 places there.

The biggest piles sit on rounded coordinates

Of the 2,811,678 distinct coordinates in that box, 5,750 are exactly
representable in four decimal places or fewer: 0.204%. Among the 107
coordinates carrying 50 or more places, 91 are: 85%. A 415-fold enrichment.
Geocoder output does not land on four-decimal values in bulk.

Not one upstream dataset

Of the 21,355 places in groups of 10 or more, by sources[].dataset:
meta 20,856, Foursquare 287, Microsoft 172, AllThePlaces 40.

confidence does not see it

The 71-place pile has a maximum confidence of 0.987 and a mean of 0.772. A
consumer filtering on confidence keeps all of it.

Also in the previous release

The same two coordinates in 2026-07-22.0 hold 80 places and 20 places.

A filter you could run

Two independent signals, tested as a union:

  1. The coordinate is exactly representable in four decimal places or fewer.
  2. Among places sharing the coordinate, at least 3 distinct
    addresses[0].postcode, and distinct postcodes are at least 40% of those
    that have one.

Postcode rather than street address, because genuine co-location has
inconsistent address strings but one postcode: Tokyo Station tenants show 15
distinct address strings across 16 places and 2 postcodes. Against every
identical-coordinate group of 7 or more in a 3km box over Chiyoda, labelled by
hand from names and addresses: 9 piles caught, 2 missed, 0 false positives, and
6 genuine co-locations correctly left alone.

Prior art

This is not a new observation, and I could not find it stated in this form.

  • #373 is open on release-to-release POI location differences, no comments
    since May 2025.
  • #463, duplicates in wrong locations, was closed as won't fix in August 2026.
  • Discussion #206
    showed Heathrow POIs with localities of Reading, Oxford and Slough in
    August 2024.
  • Discussion #372 has a
    maintainer reply attributing the drift to variation in upstream geocoders.

What I think this adds: the fault is not drift, it is exact collapse; it is
measurable; and the coordinates carry a signature you can filter on without a
geocoder.

What I did not check

  • Whether these coordinates come from upstream or are introduced during
    conflation. I can only see the published parquet.
  • Only part-00015 was scanned and every number above is the Japan bounding
    box. The same pattern is visible for South Korea in the same file
    (37.5588600,126.9998900 carries 836 places). Other parts are unscanned, so I
    do not know the global figure.
  • The labels behind the 9/2/0/6 result are my judgment from reading names and
    addresses, not field verification.
  • The filter is untested outside Japan, where postcode coverage differs.

AI assistance

Investigated with Claude Code. The direction and the decisions are mine; the
querying, the search of prior issues, and the drafting are the assistant's.
Every number above comes from the query in this issue or from the same parquet
file, and the reproduction was run as written.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by running the supplied DuckDB query against the 2026-08-19.0 places parquet and compare its results with 2026-07-22.0. Trace whether the coordinate collapse is introduced upstream or during conflation, then determine an appropriate correction or detection approach; the issue does not define a specific file, test, or final implementation.

Written by the indexing model from the issue text.

Assessment

Tech stack
sql
Domain
data
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.