BDOT10k mislabels 5 845 km² of the Baltic as a lake (source bug, not ours) #43

New issue

Open

opened 2026-08-03 08:16:03 +00:00 by art-bot · 0 comments

art-bot commented

2026-08-03 08:16:03 +00:00

Collaborator

Noticed while measuring #36. The mislabelling is in BDOT10k, not in our import — worth
saying up front, because the shape of it looks exactly like a botched union on our side.

What

map_water_bodies_<z> carries a 5 845 km² polygon named Morze Bałtyckie, classed
lake. It is the largest "lake" in the database by a factor of 29 and it is a chunk of the
Baltic.

conf/plmap.yaml's water_bodies query is WHERE rodzaj <> 'woda morska' and maps
everything surviving to river (woda płynąca) or lake. That is correct, and the source
is what is wrong. In the pl_ptwp staging table, loaded natively from the county
GeoPackages with nothing of ours applied:

      nazwa      |    rodzaj    | n  |  km2
-----------------+--------------+----+-------
 Morze Bałtyckie | woda morska  | 16 | 70995
 Morze Bałtyckie | woda stojąca |  1 |  5845   <- one row, wrong rodzaj
 Jamno           | woda stojąca |  5 |    65

Sixteen rows say marine, one says standing water. The odd one out is teryt 3209
(powiat koszaliński), centroid 54.56 N 15.79 E, and it lies 426 m from Jezioro Jamno —
which is the lagoon just north of Koszalin that is very nearly touching the sea. So the
guess that the lake infected the sea with its lakeness is probably right, and it happened
upstream of us: one county's delivery has a slab of the Baltic attributed as woda
stojąca.

Why it matters a little

It is drawn in the same blue as the sea, so nothing is visibly wrong today. This is a
data-quality and attribute-correctness problem, not a rendering one.
It survives to z5 (66 km wide, so nothing generalization does will remove it) and is 5 845
km² of polygon in every water_bodies tile along that coast.
Anything that ever reasons about water_class — a label, a marine/inland split, an
area statistic — gets it wrong. #40's bridging work reads this layer.

Options, in increasing order of dishonesty

Report it to GUGiK. It is their bug and we are a downstream consumer with a precise
reproduction.
Exclude by geometry, not by attribute — e.g. drop water_bodies polygons that touch
the country mask's seaward edge. Principled, and would catch the next one.
Name-match Morze Bałtyckie. One line, effective, and the kind of hard-coded patch
that conf/semap.yaml's objekttypnr 2648 comment warns about: the IN list that drives
the WHERE is the same list the CASE branches on precisely so an unmapped case drops
out visibly instead of being painted the wrong colour. A name check would be the
opposite of that.

Worth checking whether the same row also reaches cover (which reads the same pl_ptwp
staging table, unioned per class per county) before picking one — cover maps PTWP to its
own water classes by a different route and may or may not inherit the same error.

Noticed while measuring #36. **The mislabelling is in BDOT10k, not in our import** — worth saying up front, because the shape of it looks exactly like a botched union on our side. ## What `map_water_bodies_<z>` carries a 5 845 km² polygon named **Morze Bałtyckie**, classed `lake`. It is the largest "lake" in the database by a factor of 29 and it is a chunk of the Baltic. `conf/plmap.yaml`'s `water_bodies` query is `WHERE rodzaj <> 'woda morska'` and maps everything surviving to `river` (*woda płynąca*) or `lake`. That is correct, and the source is what is wrong. In the `pl_ptwp` staging table, loaded natively from the county GeoPackages with nothing of ours applied: ``` nazwa | rodzaj | n | km2 -----------------+--------------+----+------- Morze Bałtyckie | woda morska | 16 | 70995 Morze Bałtyckie | woda stojąca | 1 | 5845 <- one row, wrong rodzaj Jamno | woda stojąca | 5 | 65 ``` Sixteen rows say marine, one says standing water. The odd one out is **teryt 3209** (powiat koszaliński), centroid 54.56 N 15.79 E, and it lies **426 m from Jezioro Jamno** — which is the lagoon just north of Koszalin that is very nearly touching the sea. So the guess that the lake infected the sea with its lakeness is probably right, and it happened upstream of us: one county's delivery has a slab of the Baltic attributed as *woda stojąca*. ## Why it matters a little - It is drawn in the same blue as the sea, so **nothing is visibly wrong today**. This is a data-quality and attribute-correctness problem, not a rendering one. - It survives to z5 (66 km wide, so nothing generalization does will remove it) and is 5 845 km² of polygon in every `water_bodies` tile along that coast. - Anything that ever reasons about `water_class` — a label, a `marine`/`inland` split, an area statistic — gets it wrong. #40's bridging work reads this layer. ## Options, in increasing order of dishonesty 1. **Report it to GUGiK.** It is their bug and we are a downstream consumer with a precise reproduction. 2. **Exclude by geometry, not by attribute** — e.g. drop `water_bodies` polygons that touch the country mask's seaward edge. Principled, and would catch the next one. 3. **Name-match `Morze Bałtyckie`.** One line, effective, and the kind of hard-coded patch that `conf/semap.yaml`'s objekttypnr 2648 comment warns about: the `IN` list that drives the `WHERE` is the same list the `CASE` branches on precisely so an unmapped case drops out *visibly* instead of being painted the wrong colour. A name check would be the opposite of that. Worth checking whether the same row also reaches `cover` (which reads the same `pl_ptwp` staging table, unioned per class per county) before picking one — `cover` maps PTWP to its own water classes by a different route and may or may not inherit the same error.