Immutable Lake Map Packages Make Safer Rollouts

Lake maps should not drift.

If the tiles come from one build, the depth query from another, and the metadata from a third, the app can show one reality and answer from another.

That is why Meerkaartor's publish model treats a lake map as an immutable package.

One Version, Many Artifacts

A published lake package can include:

• web map tiles
• queryable depth surface
• metadata
• QA report
• provenance
• publish artifact

Those pieces belong together.

The app should be able to request version v0.1.0 and know that every artifact refers to the same build.

Immutable URLs Help Caching

Versioned assets can be cached aggressively.

If a tile URL includes a lake version, the app and CDN can keep it longer because that content should not change. A separate latest pointer can stay short-lived for discovery.

That gives users faster maps without sacrificing rollout control.

QA Is Part of the Package

Publishing is not just copying files.

The package should carry evidence that the build passed checks: coordinate system, tile tree structure, transparency, schema validity, depth query availability, and quality metrics. If an operator overrides a warning, the reason should be recorded.

That evidence is how the app knows the map is safe to consume.

Provenance Supports Reproducibility

When a user reports an issue, the team needs to know which source, settings, tools, and version produced the map.

Provenance makes that possible. It turns a visual artifact into a reproducible data product.

That matters when maps influence fishing decisions.

Rollouts Become Cleaner

Immutable lake packages let Gilli add mapped lakes without fragile manual coordination.

The backend registry can point to a version. The app can render tiles and query depth from the same contract. Future updates can publish a new version instead of mutating the old one.

Stable maps require stable publish artifacts.