Tiles are probably too heavy right now — optimization passes, measured with #139's tile tool #127

Closed
opened 2026-08-15 09:56:01 +00:00 by art · 2 comments
Owner

We just committed an acceptance test for the most crowded tile at z5 to check that it stays below 8MB, it's currently 1.8MB. 1.8MB for something that renders into 256x256 pixels on screen is way too much, an uncompressed RGBA bitmap image would be 256kB.

Run optimization passes over our layers so that generated tiles aren't too heavy, just shooting from the hip I'd say that 0.5MB is probably the upper acceptable limit for even the heaviest tiles (although I expect pushback if this intuition is wrong). Check things like if transit lines are included despite being occluded when rendering. Maybe drop street names completely on some or all streets at certain zoom levels. Make sure that all the attributes are actually needed by the style. If the style contains filters on zoom levels, that filtering belongs in the generalizations (we wouldn't need to skip rendering something if it's not there).

If hygiene no longer helps and we're still too big, roll up the enums a bit harder and simplify more.


Re-scoped 2026-08-16 (maintainer): the standardized-benchmark and
size-validation machinery that used to live in this issue moved to #139 —
a mapsrv/importer-side tile tool that serves, decodes and measures tiles from
the live DB (per-layer attribute check, 9x9-tile benchmark timing, and
per-layer/per-zoom tile-weight reports). This issue is now purely the
optimization work: make the generated tiles lighter, using #139's tool to
measure before/after and to find the heavy layers (the "check things like…"
list below stays the hypothesis list). The z5 8 MB acceptance test in
conf/common.yaml stays.

We just committed an acceptance test for the most crowded tile at z5 to check that it stays below 8MB, it's currently 1.8MB. 1.8MB for something that renders into 256x256 pixels on screen is way too much, an uncompressed RGBA bitmap image would be 256kB. Run optimization passes over our layers so that generated tiles aren't too heavy, just shooting from the hip I'd say that 0.5MB is probably the upper acceptable limit for even the heaviest tiles (although I expect pushback if this intuition is wrong). Check things like if transit lines are included despite being occluded when rendering. Maybe drop street names completely on some or all streets at certain zoom levels. Make sure that all the attributes are actually needed by the style. If the style contains filters on zoom levels, that filtering belongs in the generalizations (we wouldn't need to skip rendering something if it's not there). If hygiene no longer helps and we're still too big, roll up the enums a bit harder and simplify more. --- **Re-scoped 2026-08-16 (maintainer):** the standardized-benchmark and size-validation *machinery* that used to live in this issue moved to **#139** — a mapsrv/importer-side tile tool that serves, decodes and measures tiles from the live DB (per-layer attribute check, 9x9-tile benchmark timing, and per-layer/per-zoom tile-weight reports). This issue is now purely the **optimization work**: make the generated tiles lighter, using #139's tool to measure before/after and to find the heavy layers (the "check things like…" list below stays the hypothesis list). The z5 8 MB acceptance test in conf/common.yaml stays.
art changed title from Are tiles too heavy? to Tiles are probably too heavy right now. 2026-08-15 09:57:25 +00:00
Author
Owner

This is related to #139.

This is related to #139.
art changed title from Tiles are probably too heavy right now. to Tiles are probably too heavy right now — optimization passes, measured with #139's tile tool 2026-08-16 06:41:38 +00:00
Author
Owner

Result is in #143 — #143; the review note is the PR description. Branched on top of issue-139-tile-tool (PR #142): merge #142 first, then this — the diff is only the #127 work.

Result is in #143 — https://git.blahonga.org/art/ismap/pulls/143; the review note is the PR description. Branched on top of issue-139-tile-tool (PR #142): merge #142 first, then this — the diff is only the #127 work.
art closed this issue 2026-08-16 22:31:38 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
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#127
No description provided.