Poland's and Finland's place-name ladders go alphabetical at the top; Warszawa is rank 15 #79

Closed
opened 2026-08-09 10:35:58 +00:00 by art-bot · 1 comment
Collaborator

Found auditing every country against docs/country-requirements.md (#77). Violates R85 (top five must be the five largest cities) and R87 (break ties on the survey's own finer signal before falling back to name).

What the data says

z5 labels pl -> Białystok, Gdańsk, Katowice, Kielce
z5 labels fi -> FORSSA, HANKO, HEINOLA, HELSINKI
z5 labels se -> Stockholm, Göteborg, Västerås, Uppsala, Linköping, Malmö

Both lists are alphabetical. Warszawa is rank 15 and first appears at z7. Helsinki is rank 4.

Sweden is the control: its top tier is real cities, because #29 gave it a built-up-footprint tiebreak.

Why

Both countries tie at the top of the register's own print-size signal and fall through to name:

  • Poland — ORDER BY (split_part(skala_wyswietlania, ':', 2))::int DESC, name. Every city the register prints at the largest display scale ties, and 1,026 rows share importance 3.
  • Finland — ORDER BY importance DESC, kirjasinkoko DESC NULLS LAST, name. kirjasinkoko is coarse enough that the top font-size bucket alone covers dozens of names; 308 rows share importance 3.

#71 already documented the Finnish half as the "FORSSA over HELSINKI" case and accepted it as a data-coarseness tie. #77 raises the bar: the top of the ladder must be the actual largest settlements, so this is now a bug in both countries rather than a known limitation in one.

The fix

Find a finer signal in each register, or build a size proxy the way #29 did for Sweden — a built-up footprint area within a catchment assigned to the nearest label. R88 applies: measure in a metric CRS (EPSG:2180 for Poland, EPSG:3067 for Finland), never in EPSG:3857, or the ranking will drift north.

R33 also applies: do not touch the per-zoom caps. If the right cities are missing, the ranking signal is wrong, not N(z).

Acceptance

For both countries, SELECT name FROM map_places_14 WHERE country=$1 ORDER BY rank LIMIT 5 returns the five largest cities, with the capital first.

Found auditing every country against `docs/country-requirements.md` (#77). Violates **R85** (top five must be the five largest cities) and **R87** (break ties on the survey's own finer signal before falling back to name). ## What the data says ``` z5 labels pl -> Białystok, Gdańsk, Katowice, Kielce z5 labels fi -> FORSSA, HANKO, HEINOLA, HELSINKI z5 labels se -> Stockholm, Göteborg, Västerås, Uppsala, Linköping, Malmö ``` Both lists are alphabetical. Warszawa is **rank 15** and first appears at z7. Helsinki is rank 4. Sweden is the control: its top tier is real cities, because #29 gave it a built-up-footprint tiebreak. ## Why Both countries tie at the top of the register's own print-size signal and fall through to `name`: - **Poland** — `ORDER BY (split_part(skala_wyswietlania, ':', 2))::int DESC, name`. Every city the register prints at the largest display scale ties, and 1,026 rows share importance 3. - **Finland** — `ORDER BY importance DESC, kirjasinkoko DESC NULLS LAST, name`. `kirjasinkoko` is coarse enough that the top font-size bucket alone covers dozens of names; 308 rows share importance 3. #71 already documented the Finnish half as the "FORSSA over HELSINKI" case and accepted it as a data-coarseness tie. #77 raises the bar: the top of the ladder must be the actual largest settlements, so this is now a bug in both countries rather than a known limitation in one. ## The fix Find a finer signal in each register, or build a size proxy the way #29 did for Sweden — a built-up footprint area within a catchment assigned to the nearest label. **R88** applies: measure in a metric CRS (EPSG:2180 for Poland, EPSG:3067 for Finland), never in EPSG:3857, or the ranking will drift north. **R33** also applies: do not touch the per-zoom caps. If the right cities are missing, the ranking signal is wrong, not `N(z)`. ## Acceptance For both countries, `SELECT name FROM map_places_14 WHERE country=$1 ORDER BY rank LIMIT 5` returns the five largest cities, with the capital first.
Owner

Result is in #97 — #97; the review note is the PR description.

Result is in #97 — https://git.blahonga.org/art/ismap/pulls/97; the review note is the PR description.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
art/ismap#79
No description provided.