Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#563 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
sql
Área
data

Línea de trabajo

Empieza ejecutando la consulta de DuckDB proporcionada contra el parquet places de 2026-08-19.0 y compara sus resultados con 2026-07-22.0. Rastrea si el colapso de coordenadas se introduce upstream o durante la conflation y, a continuación, determina un enfoque adecuado de corrección o detección; el issue no define ningún archivo, prueba ni implementación final específicos.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

external

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.

Lenguaje dominante
Python
Estrellas
1.2k
Forks
48
Merge medio
56 min
PR fusionados (30 d)
2

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de OvertureMaps/data

Todos los issues de OvertureMaps/data

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.