Bridge centrelines through water polygons that have none

art-bot commented

2026-08-03 06:48:00 +00:00

Collaborator

Split out of #36, which is where the measurements come from.

What

A watercourse surveyed as an area often has no centreline through it, so once the
polygon is generalized away there is nothing left to draw and the river ends in nothing.
Counted at maxz, river-class water_bodies polygons with no waterways line intersecting
them:

	river polygons	with a centreline	without
Iceland	807	686	121
Poland	15 567	11 996	3 571
Sweden	33 368	25 541	7 827

This is what stops min_width_pixels being usable on water_bodies outside Poland. #36
added the knob and measured the orphaned area it leaves at the z9→z8 step — dropped
polygon area with no waterway within one pixel: Poland 30 km² of 1 713 (1.8%), Iceland 408
of 2 377 (17%), Sweden 1 896 of 4 433 (43%). Poland is the only country that could
turn it on, and the reason is entirely about network completeness, not about width.

Why it is probably cheap

The graph work already exists and already runs. importer/strahler.go stitches exactly
this gap for stream ordering: endpoints that die into a water polygon are bridged through
it and the nodes collapse into a super-node. It costs 67 s for Sweden's 838 973
segments, on every waterways import, today. What it does not do is materialise a
bridge as geometry — the collapse is graph-level only.

So the proposal is to emit the bridge as linework: for each water polygon that has ≥2
stream endpoints on its boundary and no line through it, add a segment joining them
(straight line first; ST_ApproximateMedialAxis from SFCGAL is the real answer and almost
certainly not needed, because the polygon is sub-pixel wide at every zoom where this
matters). The addition is on the order of thousands of two-point lines per country.

Answering the cost question from #36 directly: this is the ~1 minute end of the range, not
the ~10 hour end, because the hard part is already paid for.

Acceptance

Bridges exist for the ≥2-endpoint case; polygons with 0 or 1 endpoint on their boundary
are left alone (there is nothing to join).
Re-measure the orphaned-area table above. If Sweden and Iceland come down to Poland's
order of magnitude, turn on min_width_pixels: 1 on their water_bodies — the config
comments in conf/semap.yaml and conf/ismap.yaml name this measurement as the gate.
The acceptance test is "is the river still visible", never "does the polygon still
exist" — the same rule #36 worked under.

Split out of #36, which is where the measurements come from. ## What A watercourse surveyed as an **area** often has no centreline through it, so once the polygon is generalized away there is nothing left to draw and the river ends in nothing. Counted at maxz, river-class `water_bodies` polygons with no `waterways` line intersecting them: | | river polygons | with a centreline | without | |---|---:|---:|---:| | Iceland | 807 | 686 | **121** | | Poland | 15 567 | 11 996 | **3 571** | | Sweden | 33 368 | 25 541 | **7 827** | This is what stops `min_width_pixels` being usable on `water_bodies` outside Poland. #36 added the knob and measured the orphaned area it leaves at the z9→z8 step — dropped polygon area with no waterway within one pixel: Poland 30 km² of 1 713 (1.8%), Iceland 408 of 2 377 (17%), **Sweden 1 896 of 4 433 (43%)**. Poland is the only country that could turn it on, and the reason is entirely about network completeness, not about width. ## Why it is probably cheap **The graph work already exists and already runs.** `importer/strahler.go` stitches exactly this gap for stream ordering: endpoints that die into a water polygon are bridged through it and the nodes collapse into a super-node. It costs **67 s for Sweden's 838 973 segments**, on every `waterways` import, today. What it does *not* do is materialise a bridge as geometry — the collapse is graph-level only. So the proposal is to emit the bridge as linework: for each water polygon that has ≥2 stream endpoints on its boundary and no line through it, add a segment joining them (straight line first; `ST_ApproximateMedialAxis` from SFCGAL is the real answer and almost certainly not needed, because the polygon is sub-pixel wide at every zoom where this matters). The addition is on the order of thousands of two-point lines per country. Answering the cost question from #36 directly: this is the ~1 minute end of the range, not the ~10 hour end, *because the hard part is already paid for*. ## Acceptance - Bridges exist for the ≥2-endpoint case; polygons with 0 or 1 endpoint on their boundary are left alone (there is nothing to join). - Re-measure the orphaned-area table above. If Sweden and Iceland come down to Poland's order of magnitude, turn on `min_width_pixels: 1` on their `water_bodies` — the config comments in `conf/semap.yaml` and `conf/ismap.yaml` name this measurement as the gate. - The acceptance test is "is the river still visible", never "does the polygon still exist" — the same rule #36 worked under.

art-bot referenced this issue

2026-08-03 07:46:13 +00:00

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

art-bot referenced this issue

2026-08-03 07:48:58 +00:00

cover: absorb in one direction, and add a too-thin test #42

art-bot referenced this issue

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

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

art commented

2026-08-05 09:59:43 +00:00

Owner

Could we implement this with lines that have an extra attribute so that there's a temporary toggle in the rendering so that I can visually see the difference? Duplicate the layer in the style with some "debug-" name that only renders the lines with that particular attribute, while the original layer doesn't.

Then just make a second pull request to disable that extra attribute and clean up the style (the website mechanism to turn debug features on and off in the rendering should probably be generalized and stick around, it might be useful later).

Could we implement this with lines that have an extra attribute so that there's a temporary toggle in the rendering so that I can visually see the difference? Duplicate the layer in the style with some "debug-<original layer>" name that only renders the lines with that particular attribute, while the original layer doesn't. Then just make a second pull request to disable that extra attribute and clean up the style (the website mechanism to turn debug features on and off in the rendering should probably be generalized and stick around, it might be useful later).

art-bot was assigned by art

2026-08-05 20:40:04 +00:00

Rows
Columns

Bridge centrelines through water polygons that have none #40

What

Why it is probably cheap

Acceptance