Is this the expected behavior for Hillshade and Contours algorithms?

[guillemc23]

Hi! I'm trying to serve COP-DEM elevation data through Titiler.

The elevation data looks nice when serving the tiles as a regular WebMapTileServiceImageryProvider with Cesium.js.

My problems begin when trying to apply algorithms to this DEM layer.

For example, when applying Hillshade, I'm seeing this behavior in the borders between tiles:

I tried playing with some of the algorithm parameters but didn't manage to find a nice combination, and I don't really understand the difference between the tile's buffer property and the algorithm's buffer propery.

Also, it's interesting for my use case to apply the contours algorithm, but what I'm seeing is quite different from the docs examples:

I believe this can be related to the resolution of our DEM, but I didn't manage to form nicely defined lines, most of the time my countours it's just made up by some non-connected dots.

[vincentsarago]

I tried playing with some of the algorithm parameters but didn't manage to find a nice combination, and I don't really understand the difference between the tile's buffer property and the algorithm's buffer propery.

You need to pass buffer=3 to your tile request because by default the algorithm will assume there is a 3 pixels buffer https://github.com/developmentseed/titiler/blob/main/src/titiler/core/titiler/core/algorithm/dem.py#L22

those pixels will then be removed https://github.com/developmentseed/titiler/blob/main/src/titiler/core/titiler/core/algorithm/dem.py#L45 when returning the result

https://developmentseed.org/titiler/advanced/Algorithms/#usage

Also, it's interesting for my use case to apply the contours algorithm, but what I'm seeing is quite different from the docs examples:

Your DEM is relatively flat so if you want more contour line you'll need to adjust the algorithm parameters

titiler/src/titiler/core/titiler/core/algorithm/dem.py

Lines 73 to 77 in 0075d1c

	# parameters
	increment: int = Field(35, ge=0, le=999)
	thickness: int = Field(1, ge=0, le=10)
	minz: int = Field(-12000, ge=-99999, le=99999)
	maxz: int = Field(8000, ge=-99999, le=99999)

https://developmentseed.org/titiler/examples/notebooks/Working_with_Algorithm/#pass-parameters-to-the-algorithm

[guillemc23]

hi @vincentsarago , thanks for your answer.

You need to pass buffer=3 to your tile request because by default the algorithm will assume there is a 3 pixels buffer https://github.com/developmentseed/titiler/blob/main/src/titiler/core/titiler/core/algorithm/dem.py#L22

I tested this, as well as applying 0 and 0 to the tile's buffer and algorithm buffer. I have a feeling that I'm still seeing the lines, even if they look thinner. Is this also related to the scale param? I have a feeling that higher scale (e.g 4) shows less lines. Also, from my understanding, the algorithm's buffer is needed to compute the hillshade in the edges of the tile, so that it knows the slope at $n-1$. In this case, would it make sense to add a bigger buffer like 32 and 32 both in the algorithm's buffer parameter and the tile buffer parameter?

Your DEM is relatively flat so if you want more contour line you'll need to adjust the algorithm parameters

I tested this as well, but didn't manage to find a nice solution. I tested a higher resolution DEM (2 m) and it did work better... but in any case, it might be useful to resample the DEM so that there are more pixels to draw the lines and to scale the DEM values only for visualization purposes (let's say 1.5x) so that the slopes are bigger and there's more room to paint them? I have a feeling that with this resolution (30 m for COP-DEM) the contours take at least 30m to be drawn and that's why it's too much compared to the flatness of most of the DEMs

[vincentsarago]

hillshade

I tested this, as well as applying 0 and 0 to the tile's buffer and algorithm buffer

For the hillshade also you should always use a tile buffer!

In this case, would it make sense to add a bigger buffer like 32 and 32 both in the algorithm's buffer parameter and the tile buffer parameter?

Did you test this? The issue using bigger buffer mean it could fetch way more GeoTIFF internal blocks and thus result in a slow tile request. But again this is let to the user to decide which buffer is best for them.

The tile edge might also be showing when doing over-zooming: #980 (comment)

Contours

(let's say 1.5x) so that the slopes are bigger and there's more room to paint them? I have a feeling that with this resolution (30 m for COP-DEM) the contours take at least 30m to be drawn and that's why it's too much compared to the flatness of most of the DEMs

Yeah might be a solution, maybe you can customize the Algorithm but even if you upscale the resolution you'll have to downscale the output image so it might give similar result 🤷‍♂️

FYI: I didn't write the contours algorithm but was adapted from https://custom-scripts.sentinel-hub.com/dem/contour-lines/ so TBH I don't know much.

[guillemc23]

Hey Vincent! Could not reply earlier, I had to take care of other stuff 😄

Did you test this? The issue using bigger buffer mean it could fetch way more GeoTIFF internal blocks and thus result in a slow tile request. But again this is let to the user to decide which buffer is best for them.

I did try, it works but it is noticeably slower. Setting buffer in both the tile request and algorithm works as long as it's the same amount in both parameters. I'm still seeing a very light line separating the tiles, it gest reduced when using scale=4, you can see it in the image below. It's very light but still visible, not sure if this is as it should be:

Yeah might be a solution, maybe you can customize the Algorithm but even if you upscale the resolution you'll have to downscale the output image so it might give similar result 🤷‍♂️

This I haven't been able to try yet but I will some time in the future and let you know how it goes 😄