Skip to main content

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.

bathymetrymap-tileslake-mapsgilli