Generate MVT Contour Line Tiles From Elevation Data

[anjx123]

Contour Lines are a classic map style feature that users may want to generate given some elevation data. Adding this feature to Martin tile server would be highly cacheable without the client needing to actually download any elevation data.

Steps

• Decode data format into a raw 2D elevation buffer.
• Use contour rust crate to generate isoline geometries, exposing configurable parameters.
• Isoline geometries are geo-types Geometry::LineString that can then be scaled and transformed into MVT space.
• Geometry are then converted to MVT tiles that can be served. Metadata can be encoded for features like major and minor contour lines.

[anjx123]

This is something that I would be interested in taking up the work to integrate into the tile server. I potentially have a working prototype that we can use as a starting point for discussions.

[nyurik]

I think this would be an awesome feature, and it ties a little bit with the #2054 because it also constructs MVTs on the fly.

TBD:

• what's output MVT layer structure and attributes?
• what should the YAML configuration be for this feature?
• what should the CLI params be?
• my understanding is that this feature needs upstream data, e.g. elevation files (DEM?), which might not be locally available -- should we start with a forwarding service first, i.e. ability for Martin to forward requests elsewhere? Once implemented, that sub-service could be reused by other backends like this one.

[CommanderStorm]

ähm.. lets step back one second.

What would you like to do? In above picture you have hill-shading => you are already downloading the DEMs.
Is the following example maybe a simpler solution?
=> https://maplibre.org/maplibre-gl-js/docs/examples/add-contour-lines/

[anjx123]

Hey @CommanderStorm, thanks for getting back to me on this one.

I apologize for not clarifying fully in my initial post, you're correct that maplibre-gl-js offers a good client-side solution for generating contour lines, and makes sense for many projects. However, our use case is a little different, as it involves the MapLibre Native project and a strict CPU budget on the client. For this reason, we ideally wanted to pre-compute the contour lines on the server, and make them available as vector tiles that clients can simply fetch and render. Which also allowing for more centralized caching as well.

This connects to @nyurik's last question about whats the data source. To clarify, the client themselves will not be processing or fetching the DEM data and Martin will act more as a forwarding service that handles that work. Our prototype uses the open source Amazon S3 Mapzen terrarium elevation tiles bucket (link), which we found works well for fetching all the DEM data and centralizing processing on the server.

Let me know if this align's with Martin's long term goals, but I suppose the core of our proposal is to introduce a new kind of data source for Martin. Alongside the existing Database sources that Martin pulls from, the remote raster DEM endpoint could take a significant load off the client, and potentially be more flexible and powerful to work with.

[CommanderStorm]

Sure, sounds reasonable.

We have a style-spec proposal ongoing, but this is still a bit in the finding phase:

• Design Proposal: Contour Line Source from Raster DEM Tiles maplibre-style-spec#583

[CommanderStorm]

I am a bit unsure how exactly this would work configuration wise 🤔

So how are DEMs stored in practice? => do we need multiple storage formats?
And regarding integration:

• Should this be its source or
• something plugin-esque integrated like the cache.

Depending on how hard the underlying algorithm for conversion is to get right, it might be simplest to do this similar to COGs => an experimental/docs-hidden source until it fully works

[anjx123]

Valid questions, I've been thinking:

Data Storage:
My current prototype uses the Terrarium PNG format which encodes elevation in RGB channels, and is easy to fetch and parse without local storage. Ultimately, the PNG is parsed into a 2D elevation matrix which acts as a common interface used for various tasks like contour generation. This means that in the future, we could potentially support contour line generation from elevation data from existing backends like PostGIS or MBTiles, giving users more flexibility.

Integration:
The engineering problem is then essentially two-fold:

1. Introduce a new dem source type. Where this new source would handle fetching and decoding the elevation data from remote endpoints like the Terrarium PNG format.
2. Add a new processing layer. Where this layer would consume the decoded 2D elevation matrix and generate the vector tiles for the contour lines. For the initial implementation, I think it makes sense to tie this new processing layer exclusively to the new dem source. And we can always expand to other backends if there is a request for it later on.

Experimental:
Yeah I agree. It makes sense to prototype this and get a clean design solidified before deployment.

[CommanderStorm]

Sounds good.
I am not sure if we need to decode that data, except for postprocessing. Your subject knowlege is higher on this.

On the processing layer, maybe we can reduce the work nessesary and push this into the source itsself:

@wipfli maybe you could weigh in on this, given your work on mapterhorn.

How are DEMs in your oppinion usually stored (mbtiles, pmtiles, plain bucket)?
Would "being generic over these sources" even make sense?