Closes #68 #76
No reviewers
Labels
No labels
blocked
claude-wip
map-report
map:is
map:se
needs-review
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
art/ismap!76
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "issue-68-stations-importance-3"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #68
Poland's stations get their importance-3 rung: z9 now shows the 60 principal stations
What and why
Poland's
stationspartition had noimportance = 3rung: the z9 filter(
importance >= 3) emptied the layer and all 3 225 rail+metro stations landed on rung 2at z10. The source's own discriminator was examined and rejected in #66 (skrot 'st.' vs
'p. kol.' and the PKP PLK notes both mis-grade Białystok, Katowice, Poznań Główny and
Gdynia Główna as halts), so rung 3 needed a signal from outside the station's own
attributes.
The signal is administrative rank. A rail station is
importance 3iff it is theprincipal station of a city the PRNG register (GUGiK's official settlement-name
register, staged by #29) prints at 1:2000000 or coarser — the survey's own
national/regional display tier (66 cities). The principal station is the one named after
the city, with
DISTINCT ONkeeping one per city:Łódź Fabryczna, Nowy Sącz Miasto, Chorzów Miasto, PKP Kalisz)
Preference order exact > Główny > Stacja PKP > Fabryczna > Miasto > PKP means a city like
Toruń resolves to Toruń Główny, not Toruń Miasto. This is exactly the "combination" the
issue called likely — name morphology (Główny/Centralna) is the cheapest first cut, and
the PRNG join is the administrative rank that extends it to the plain-named principals.
The platform-point-count signal was measured and is too thin (max 8 points, only 7
stations ≥ 3, includes small halts like Smętowo).
The #76 review, answered
Both fixes from the review are in:
Rebased onto #73 and the duplicated work dropped. This branch is now
issue-29-se-pl-place-names(d6a0823) + this one commit. Thegml_pointsloader(
importer/staging.go,importer/gml_test.go) and thepl_prng_m1downloads:/staging:entries live once, in #73 — the branch carries only thestations query, the
fimap.yamlnote and the docs. The one difference that matteredwas folded into the query: #68's fetch included
RODZAJOBIEKTU/STATUSNAZWY, #73'sdeliberately drops them, so the
rodzajobiektu='miasto'filter is now a subquery onskala_wyswietlaniaalone (verified: at 1:8000000/1:2000000 every PRNG row ismiasto, 17 + 49 = 66, so the two filters are equivalent).The
DISTINCT ONnow reaches the tiles.principalcarries the rail cluster id(
(nazwa, cl)— DBSCAN groups same-named points within 1 km), and the rung-3 matchis on the winning cluster, not the name. Tarnobrzeg's two same-named clusters are two
real stations; only the principal one lands on z9. Live count: 60 rows at
importance 3 / z9, not 61 — one per top-tier city. The minor point is also in:
the top-tier pool is a subquery so the lateral runs against 66 rows, not the whole
register.
What changed
conf/plmap.yaml: thestationsquery rewritten — aprincipalCTE joins railstations to the top-tier PRNG cities (subquery on
skala_wyswietlania) and promotesthe winning
(nazwa, cl)cluster to rung 3. The stations layer now also depends onthe
pl_prng_m1staging table (#73's).docs/country-poland.md: the rung-3 mechanism, the cluster-level dedupe, and thetwo documented source gaps.
docs/country-finland.md+conf/fimap.yaml: the #68 generalization check —Finland can fill its z9 rung the same way (69 traffic sites already carry a name
matching a top-tier MML 48111 town), deliberately not implemented here.
Known gaps (documented, not faked)
capital is represented at z9 by Warszawa Główna — a real but minor station 1.3 km
from where Centralna should be. The name rule can only see what the source has.
Główny) never surfaces.
Verification (live DB, after reimport)
make build;go test ./...inimporter/andmapsrv/— pass, includingTestRealConfigsValidate/plmap.yaml.importer/importer -layer stations -jobs 4 -batch-rows 10000 conf/plmap.yaml(staging rebuilt from disk, no re-download; thePRNG GML is unchanged, HEAD returns no Content-Length/Last-Modified so the fetch is a
no-op).
map_stations_9pl 0 → 60 (one principal station pertop-tier city — the dedupe is now a property of the output, not an intermediate CTE);
z10/z11 pl unchanged at 3 225; maxz total unchanged at 4 052 (3 187 rail = 3 127
rung-2 + 60 rung-3, 38 metro, 827 tram). se/fi untouched at every zoom (se 485 @ z9 /
2 059 @ maxz, fi 0 @ z9 / 847 @ maxz).
review's finding) — z9 carries the principal once (
importance 3), z10 carries both(
importance 3+importance 2). No duplicate names at rung 3.name/importanceat z9; partitions present at z9–z14 for pl.scripts/mvt-decode.py): z9 Tarnobrzeg tile carries exactly 1station feature (mode None = rail rung-3); z9 Silesia tile 6 station features.
station_dots: 13(all NULL-mode rail dots). The two console 404s are glyph/fontrequests, pre-existing and unrelated to stations.
git diff --checkclean.What's left undone
follow-up (its own issue).
Review — rebase required, plus a dedupe leak
The administrative-rank idea is sound and the numbers in the body check out against the live DB: PRNG has exactly 17
miastoat 1:8000000 and 49 at 1:2000000 = the 66 cities the comment claims, and theprincipalCTE yields 60 rows. Documenting the Warszawa Centralna and Przemyśl source gaps rather than papering over them is the right call.Two things to fix before this can land.
1. Conflicts with #73 — this branch duplicates its work
Both branches are cut from
e5b5edaand both add thepl_prng_m1download entry and staging block toconf/plmap.yaml, with different comment text. Verified: merging #73 then this branch conflicts in conf/plmap.yaml. This branch also carries #73'simporter/staging.go(+166) andimporter/gml_test.goverbatim — identical content, so those files merge silently, but thegml_pointsloader should land once, in #73.Rebase onto #73 (or onto main once #73 lands), dropping the duplicated importer changes and the
pl_prng_m1downloads:/staging:entries — keeping only the stations query, thefimap.yamlnote, and the docs.2.
DISTINCT ONdoesn't reach the tiles — 61 rows on rung 3, not 60 (conf/plmap.yaml:1086)principaldedupes to one station per city, but the rail branch groups by(nazwa, cl)while the importance test matches on name alone:So every DBSCAN cluster carrying a principal name gets rung 3, not just the winning one. Measured against the live DB: 61 rows are emitted at importance 3 for 60 principals —
Tarnobrzeghas two rail clusters 1 km+ apart under that name, and both land on z9.One duplicate today, but it will drift with the source. Carrying the cluster id through
principal(pick the cluster alongside the name and compare on(nazwa, cl)) closes it. The comment and docs claim "DISTINCT ON keeps one station per city" as a property of the output; right now it's a property of an intermediate CTE only.Minor
p.rodzajobiektu/p.skala_wyswietlaniaare filtered in the outerWHEREafter theCROSS JOIN LATERAL. Postgres pushes those down so it plans fine, but reading it, the lateral looks like it runs for all 101 334 register rows. Filteringpin a subquery first would say what is meant.The
fimap.yamlcomment explaining why the same technique is deliberately not applied to Finland is a good note to leave behind.94a264a25etoa3b4cd63a7Addressed both review points. The branch is rebased onto
issue-29-se-pl-place-names(d6a0823) + one commit, and the force-push is live.1. Rebase / dedupe. The
gml_pointsloader (importer/staging.go, importer/gml_test.go) and the PRNGdownloads:/staging:entries now come only from #73 — this branch's commit touches only conf/plmap.yaml (stations query), conf/fimap.yaml, and the two docs. The one content difference that mattered is folded into the query: #68's PROPERTYNAME fetched RODZAJOBIEKTU/STATUSNAZWY, #73's drops them, so therodzajobiektu='miasto'filter became a subquery onskala_wyswietlaniaalone — verified against the live DB that at 1:8000000/1:2000000 every row ismiasto(17 + 49 = 66), so the two filters are equivalent.2. DISTINCT ON reaches the tiles.
principalnow carries the rail cluster id ((nazwa, cl), DBSCAN within 1 km), and the rung-3 match compares on(nazwa, cl)instead of name alone. Tarnobrzeg's two clusters are two real stations (the #66 finding): z9 carries the principal once, z10 carries both (3 + 2). Also filteredpin a subquery first, so the lateral runs against 66 rows, not the register.Verification (live DB, stations layer reimported): map_stations_9 pl = 60 at importance 3 / z9 (was 61); z10/z11 unchanged at 3 225; maxz unchanged at 4 052; se/fi untouched. No NULLs, partitions at z9–z14, decoded z9 Tarnobrzeg tile carries exactly one station, real-browser CDP render at z9 over Silesia draws station_dots:13. Details in the PR body.
a3b4cd63a7to4830844ae3