The Lake Registry Is Product Infrastructure

For Gilli, the registry decides which lakes have mapped coverage, where their bounds are, which tile version is active, whether point-depth queries are available, and what metadata the app can trust.

That makes it product infrastructure.

Names Are Not Enough

A lake entry needs a stable ID.

It also needs display name, geographic bounds, published version, tile URL template, metadata URL, depth query template, depth availability, and max-depth context. Without those fields, the app cannot safely decide how to render or query the lake.

The registry is what prevents guesswork.

Depth Availability Must Be Explicit

A lake can be known before it is depth-enabled.

That matters for rollouts. Gilli can show a lake in the registry or prepare tile overlays while still refusing to return point-depth until the published bathymetry package exists.

That is better than faking depth or returning a max-depth value as if it were sampled.

Bounds Are a First Filter

When the user taps a coordinate, the backend needs to know whether that point is inside a mapped lake candidate.

Bounds are not the final geometry truth, but they are a useful first filter. They let the backend route the request to lake bathymetry, marine fallback, or no-depth behavior.

The backend owns the decision and keeps the app simple.

Versions Keep Layers Together

Tiles, metadata, QA, provenance, and depth surfaces should belong to the same published version.

If the visual map and point-depth query drift apart, users can see one thing and receive another answer. Versioned lake packages prevent that.

This is why immutable publish artifacts matter.

The Registry Lets Mapping Scale

Manual entries are fine for the first lakes.

Over time, publishing a new lake should make it discoverable with minimal app changes. The registry is the bridge between the mapping pipeline and the fishing product.

It turns mapped water into app behavior.