rendering issue #37
Labels
No labels
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#37
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
At specifically zoom 17 this renders badly. Looks like a problem with too small buffer around the MVT.
Location: z18 / 52.23002 / 20.91506
Feature:
cover— country=pl, cover_class=transportArea: circle r=127 m @ 52.23020, 20.91504
Investigation complete (2026-08-04, night-shift run; worker hit its iteration cap before committing — nothing to push, hence release rather than blocked).
Finding: the buffer is not the visible cause. A systematic A/B comparison (buffer 64 vs 256, pixel-traced renders at z17.51 and z18 at 52.230019/20.915062) produced 0-pixel diffs: opaque cover fills hide buffer-edge clipping, adjacent-tile fragments stay seamless, and the reported polygon renders exactly at its DB geometry (edge pixels match to ≤2 px). The 'white areas' in the report are roads (roads_secondary/_tertiary/_minor, up to ~60 px wide at z17) and the purple lines are transit_tram — confirmed via queryRenderedFeatures per pixel. Not missing fill.
Hard clipping at the buffer line IS real in the decoded MVTs (coords exactly at x=4160=4096+64 / y=-64), it just isn't visible for opaque fills.
Recommendation (maintainer's call): (a) raise the buffer 64→256 in importer/shared.go + layer.go as a defensive improvement — measured cost 7–34% on z17 transport tiles, redeploy via one importer run — or (b) accept that no visible defect is reproducible at buffer 64 today and close/re-scope this issue. Full detail in the delegation transcript if wanted.
night-shift — released, not worked.
Worker hit its iteration cap after completing the investigation (buffer not the visible cause — see comment). No commits to keep; re-queued for a maintainer decision on the recommendation.
Attached two screenshots from two different countries, in the first the right lane of "Powstańców Śląskich" renders completely wrong, in the second we can see that the north edge of Hägerstensvägen is all wrong. Just the fact that we can't see the casing and can see one of the street segments ending (with that rounded cap) should tell us that something is wrong.
If it's not a buffer issue in the MVT, then what's causing this? The next agent that picks up this issue, please add a comment with screenshots of the verification of this particular intersection (Powstańców Śląskich and Czulhowska) at zoom level 19 (19 is worse even than 17 and 18) with different buffer settings in the MVT (changing the MVT function for one test should be trivial).
Verification of the buffer hypothesis at the reported intersection (Powstańców Śląskich × Człuchowska, Warsaw) and the second data point (Hägerstensvägen, Stockholm), both at z19 — exactly as asked.
Method. Rendered the same cameras at MVT buffer 64 (current) and 256 (test) via real Chrome over CDP (
scripts/cdp-map-check.mjs, no virtual time), 2 renders per buffer. Same-buffer controls are 0-pixel diffs; the cross-buffer diff is real and concentrated at tile edges.Result — the artifact IS the buffer cut, and b256 fixes it.
line-cap: roundthere, so the casing is missing on one side and segments end mid-road with a rounded cap. At b256 the clip moves to 4352 (= 4096+256), the road extends past the seam, and the casing/cap artifact is gone.Tile-size cost at z19 (hex-encoded
zxy_mapbytes, b64 → b256, five tiles around the Warsaw intersection): 596→677 (+14%), 576→623 (+8%), 430→494 (+15%), 378→451 (+19%), 504→561 (+11%). The roads layer alone is +4% to +21% per tile. Modest, and only the stroked layers pay it — the opaque cover fills render identically (the earlier 0-diff finding was fill-only, as suspected).Screenshots: left = buffer 64 (artifact: casing break / rounded cap at the seam), right = buffer 256 (clean).
The fix is in #59 — #59; the review note is the PR description. b256 A/B verification (screenshots above) shows the casing/cap artifact at the reported intersection is gone.