GILLI · · 4 min read
Bathymetry Tiles Are Not Depth Queries
A beautiful contour tile and a point-depth answer are different products. Gilli needs both: visual structure for scanning and queryable depth for decisions.
A bathymetry tile is an image.
A depth query is an answer.
They are related, but they are not the same feature.
Tiles let anglers scan the lake. They show contours, bands, shelves, basins, and visual structure. A point-depth query tells you the estimated depth at a coordinate. One is for seeing. The other is for asking.
Gilli needs both.
Why Tiles Matter
Map tiles are the right way to render bathymetry smoothly inside a mobile map.
They load quickly. They can be cached. They can be styled with depth bands, contour lines, transparency, and hillshade. They give anglers the broad picture: where the basin sits, where the shoreline drops, where the shallow flats transition into deeper water.
For planning, this is essential.
An angler can look at the map and form a hypothesis before fishing.
Why Tiles Are Not Enough
Tiles are pixels. They are not the source of truth for sampled depth.
If the app tries to infer depth from tile color, it will be brittle and inaccurate. Style changes would change the answer. Compression, transparency, and visual ramps would become data problems. That is the wrong layer.
A proper point-depth query should read the underlying bathymetry surface, not the rendered PNG.
That is why the lake mapping pipeline publishes both visual tiles and a queryable depth surface.
The Better Contract
The clean contract is:
- tiles for rendering
- metadata for bounds, version, coverage, and provenance
- depth surface for coordinate queries
- QA report for publish confidence
With that structure, Gilli can render the lake visually and still ask the backend for a real sampled depth when the user taps.
The backend can also return whether the result came from lake bathymetry, marine fallback, or no available coverage.
That source label matters.
Immutable Versions Build Trust
Lake maps should be versioned.
If a lake package is published as a specific version, its tiles, metadata, depth surface, QA report, and provenance should travel together. That makes rollouts safer. It also lets the app cache aggressively without wondering whether a tile and a depth query came from different map builds.
When a new lake map is published, it can move through the same contract.
No hidden state. No guessing.
What the User Gets
The angler sees a clean map.
When they tap, they get a depth answer. If it is a mapped lake, the app can say so. If it is marine fallback, it can say that too. If no depth exists, it should not invent one.
That is how a bathymetry feature becomes useful field intelligence instead of decoration.
Related notes
GILLI · 6 May 2026 · 4 min read
Turbidity Changes How Fish Hunt
Water clarity is not just an angler comfort metric. It changes predator vision, prey behavior, and the usefulness of different tactics.
GILLI · 6 May 2026 · 4 min read
Species Queues Before Runtime Species
The safe way to expand a fishing app is to research species in a queue before promoting them into runtime forecasts.
GILLI · 6 May 2026 · 4 min read
Solunar Is a Modifier, Not a Magic Clock
Moon and solunar windows can be useful context, but they should never overpower temperature, oxygen, clarity, tide, and species behavior.