Gå til hovedindhold

GILLI · · 4 min read

From Lake Request to Published Map

A lake request should move through a reproducible mapping pipeline: ingest, preprocess, georeference, tile, QA, publish, then app integration.

When someone asks Gilli to add a lake, the work is not "draw some contours."

A lake map has to become a reliable app artifact. That means it needs a pipeline, a version, metadata, quality checks, provenance, and a serving contract the app can understand.

That is the shape of the Meerkaartor workflow.

Ingest

The first step is source handling.

What is the input? A scanned chart, GIS file, depth dataset, shoreline reference, or manual contour source? What is its coordinate system? What license applies? What lake boundary should constrain it?

Bad source handling cannot be fixed by pretty rendering later.

Preprocess and Georeference

Raw inputs need alignment.

If a chart is scanned, it must be georeferenced. If contours are extracted, they need cleaning and validation. If shoreline constraints exist, they need to match the lake boundary. The output has to land in a coordinate reference system suitable for web maps.

This is where a lake map becomes spatial data instead of an image.

Build the Depth Surface

Contours and constraints are turned into a bathymetric surface.

That surface should preserve contour order, respect shoreline zero depth, avoid impossible artifacts, and carry uncertainty where appropriate. The surface is what later powers point-depth queries.

If this step is weak, every downstream feature inherits the weakness.

Render Tiles

Tiles make the map usable in the app.

They need the right projection, XYZ path structure, tile size, transparency outside coverage, and stable URL templates. They should be style-consistent and readable on mobile.

The app should not need to understand the whole pipeline. It should receive a clean tile contract.

QA and Publish

Before a lake reaches Gilli, it should produce machine-readable artifacts:

  • metadata
  • QA report
  • provenance
  • publish manifest
  • versioned tiles
  • queryable depth surface

Publishing should be blocked when critical checks fail. Warnings can exist, but they need an audit trail.

App Integration

Once published, Gilli can use the lake in two ways.

The visual layer shows bathymetry tiles on the map. The query layer returns estimated depth at a tapped or GPS coordinate. Both point back to the same versioned lake package.

That is how a user request becomes a stable product feature.

Not a one-off image.

A reproducible lake map.

lake-mappingbathymetryworkflowgilli