art/ismap
1
0
Fork 0
Code Issues 18 Pull requests 1 Projects Releases Packages Wiki Activity Actions

Waterways: wide rivers vanish at coarse zoom before their feeder streams do #20

New issue
Closed
opened 2026-08-01 19:12:55 +00:00 by art-bot · 2 comments
art-bot commented 2026-08-01 19:12:55 +00:00
Collaborator
Copy link

Tune the water zoom_filters so a few more rivers stay visible at coarse zoom. The
visible symptom is a mismatch between two independent thinning mechanisms: water_bodies
drops polygons below min_area_pixels, while waterways thins on the importance ladder —
so a wide river mapped as a polygon can disappear while the thin streams feeding it are
still drawn, which reads as a bug even though each layer is behaving as configured.

Check all three countries before turning a knob. This used to be an Iceland question and
is now a three-country one, and the countries reach importance by different routes:
Strahler stream order (Iceland, Sweden) versus surveyed channel width (Poland). A threshold
that looks right in one may not be in another. docs/country-*.md has each derivation.

Note that water_bodies' min_area_pixels was raised from 1 to 16 for Sweden and Poland in
the 2026-08-01 generalization work, which will have moved this — re-measure before
assuming the old behaviour. -regeneralize makes the experiment cheap.

Tune the water `zoom_filters` so a few more rivers stay visible at coarse zoom. The visible symptom is a mismatch between two independent thinning mechanisms: `water_bodies` drops polygons below `min_area_pixels`, while `waterways` thins on the `importance` ladder — so a **wide river mapped as a polygon can disappear while the thin streams feeding it are still drawn**, which reads as a bug even though each layer is behaving as configured. **Check all three countries before turning a knob.** This used to be an Iceland question and is now a three-country one, and the countries reach `importance` by different routes: Strahler stream order (Iceland, Sweden) versus surveyed channel width (Poland). A threshold that looks right in one may not be in another. `docs/country-*.md` has each derivation. Note that `water_bodies`' `min_area_pixels` was raised from 1 to 16 for Sweden and Poland in the 2026-08-01 generalization work, which will have moved this — re-measure before assuming the old behaviour. `-regeneralize` makes the experiment cheap.
art-bot commented 2026-08-03 07:46:13 +00:00
Author
Collaborator
Copy link

Closing, but the resolution changed shape twice and that is worth recording, because the
issue as filed asks for a knob and the answer turned out to be a mechanism.

First fix (3ae69c3): keep the polygon. water_bodies.min_area_pixels went 16 → 4 for
Sweden and Poland, so a wide river's own polygon survives to coarse zoom and renders as a
hairline instead of vanishing.

Second (#36): collapse it to the centreline, in Poland only. min_width_pixels: 1 on
Poland's water_bodies deliberately drops a river polygon once it is under a pixel wide —
which is the cartographically standard answer, and takes Poland's river polygons from
1 180 / 229 / 35 at z9 / z7 / z6 to 180 / 4 / 0.

That reads like this issue reopening, and it is not, because the bug here was an
inversion — a trunk missing while the streams feeding it were still drawn — not a polygon
being absent. At z6 Poland draws 790 watercourses, every one of them importance >= 5, so
no inversion is representable; and the trunks are all there:

importance drawn at z6
Wisła 5 1 331 km
Odra 5 638 km
Bug 5 276 km
San 5 164 km
Narew 5 112 km
Warta 5 110 km

Confirmed visually at z5/z6/z7: the Vistula runs unbroken through Warszawa at every one.

Sweden and Iceland keep their polygons and are unchanged by #36. They do not get the
knob because their waterways networks do not cover what it would remove — the same z9→z8
test orphans 1 river polygon of 412 in Poland, but 43% of dropped area in Sweden and 17% in
Iceland. Sweden's centrelines stop at its water polygons (21% of segment endpoints lie
within 30 m of one), so a river area often has no line through it at any zoom. That is
#40, which proposes materialising the bridges strahler.go already computes; the
config comments in conf/semap.yaml and conf/ismap.yaml name the measurement to re-run
before turning the knob on there.

Measurements in docs/performance.md, "Area was the wrong measure…".

Closing, but the resolution changed shape twice and that is worth recording, because the issue as filed asks for a knob and the answer turned out to be a mechanism. **First fix (`3ae69c3`): keep the polygon.** `water_bodies.min_area_pixels` went 16 → 4 for Sweden and Poland, so a wide river's own polygon survives to coarse zoom and renders as a hairline instead of vanishing. **Second (#36): collapse it to the centreline, in Poland only.** `min_width_pixels: 1` on Poland's `water_bodies` deliberately drops a river polygon once it is under a pixel wide — which is the cartographically standard answer, and takes Poland's river polygons from 1 180 / 229 / 35 at z9 / z7 / z6 to **180 / 4 / 0**. That reads like this issue reopening, and it is not, because **the bug here was an inversion** — a trunk missing while the streams feeding it were still drawn — not a polygon being absent. At z6 Poland draws 790 watercourses, every one of them `importance >= 5`, so no inversion is representable; and the trunks are all there: | | importance | drawn at z6 | |---|---:|---:| | Wisła | 5 | 1 331 km | | Odra | 5 | 638 km | | Bug | 5 | 276 km | | San | 5 | 164 km | | Narew | 5 | 112 km | | Warta | 5 | 110 km | Confirmed visually at z5/z6/z7: the Vistula runs unbroken through Warszawa at every one. **Sweden and Iceland keep their polygons** and are unchanged by #36. They do not get the knob because their `waterways` networks do not cover what it would remove — the same z9→z8 test orphans 1 river polygon of 412 in Poland, but 43% of dropped area in Sweden and 17% in Iceland. Sweden's centrelines *stop at* its water polygons (21% of segment endpoints lie within 30 m of one), so a river area often has no line through it at any zoom. That is **#40**, which proposes materialising the bridges `strahler.go` already computes; the config comments in `conf/semap.yaml` and `conf/ismap.yaml` name the measurement to re-run before turning the knob on there. Measurements in `docs/performance.md`, "Area was the wrong measure…".
art-bot commented 2026-08-03 08:02:58 +00:00
Author
Collaborator
Copy link

Correction to what I wrote above. I said Poland's river polygons "go to zero at z6" and
that the river is "drawn as a centreline there instead". The first half is true only of the
river-classed polygons, and the sentence as a whole gives the wrong impression. Poland
still has 47 water polygons at z6, and the wide parts of the Vistula are among them.

BDOT10k classes an impoundment as woda stojąca — standing water — so a reservoir on a
river comes through as lake, not river. Two segments of Jezioro Włocławskie, the
Włocławek reservoir on the Vistula, are 79 km² and 62 km² at 3 542 m and 4 004 m wide.
One pixel at z6 is 2 446 m, so they are 1.4 px wide and the rule keeps them. At z5 a pixel
is 4 892 m, they are 0.7 px, and the rule drops them — which is exactly the "loses some
segments at z5, but not all" behaviour, and it is the rule working, not failing.

What is left at z5 is the four things still over a pixel wide: Morze Bałtyckie (66 km),
Śniardwy (10.9 km), Łebsko (8.3 km), Dąbie (8.3 km).

Also worth correcting: cover's water class is not what paints the Vistula at coarse
zoom. Measured against the Wisła's 1 331 km of centreline, cover water lies on 67% of it
at z9, 7.5% at z7 and 1.3% at z6 — so below z7 the river is carried by waterways plus
the surviving impoundment polygons, not by the landcover coverage. That is the correct
behaviour but it is not what I implied.

Rendered before/after at z5/z6/z7 over the Włocławek reach: z6 is indistinguishable, z7
shows the reservoir as a slightly narrower band, and the river is continuous at every zoom
in both. The layer rebuild for the comparison was -regeneralize 5-13, 2.5 min each way,
and the config is back as committed.

**Correction to what I wrote above.** I said Poland's river polygons "go to zero at z6" and that the river is "drawn as a centreline there instead". The first half is true only of the `river`-*classed* polygons, and the sentence as a whole gives the wrong impression. Poland still has **47 water polygons at z6**, and the wide parts of the Vistula are among them. BDOT10k classes an impoundment as *woda stojąca* — standing water — so a reservoir on a river comes through as `lake`, not `river`. Two segments of **Jezioro Włocławskie**, the Włocławek reservoir on the Vistula, are 79 km² and 62 km² at **3 542 m and 4 004 m wide**. One pixel at z6 is 2 446 m, so they are 1.4 px wide and the rule keeps them. At z5 a pixel is 4 892 m, they are 0.7 px, and the rule drops them — which is exactly the "loses some segments at z5, but not all" behaviour, and it is the rule working, not failing. What is left at z5 is the four things still over a pixel wide: Morze Bałtyckie (66 km), Śniardwy (10.9 km), Łebsko (8.3 km), Dąbie (8.3 km). Also worth correcting: `cover`'s water class is **not** what paints the Vistula at coarse zoom. Measured against the Wisła's 1 331 km of centreline, `cover` water lies on 67% of it at z9, 7.5% at z7 and **1.3% at z6** — so below z7 the river is carried by `waterways` plus the surviving impoundment polygons, not by the landcover coverage. That is the correct behaviour but it is not what I implied. Rendered before/after at z5/z6/z7 over the Włocławek reach: **z6 is indistinguishable**, z7 shows the reservoir as a slightly narrower band, and the river is continuous at every zoom in both. The layer rebuild for the comparison was `-regeneralize 5-13`, 2.5 min each way, and the config is back as committed.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
night/issue-62-water-flow
night/issue-47-water-coastline
No results found.
Labels
Clear labels   
claude-wip
night-shift

  
map-report
map data feedback (mapsrv)

  
map:is
map data feedback (mapsrv)

  
map:se
map data feedback (mapsrv)

  
needs-review
night-shift

No labels
claude-wip
map-report
map:is
map:se
needs-review
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
art-bot
1 participant
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#20
No description provided.