GeoTIFF serialization for isochrones

[chrstnbwnkl]

Issue

Adds GeoTIFF as an output format to the isochrones endpoint, which returns the 2-D grid as a raster instead of contours.

The rough idea is this: when a user requests a raster output by specifing "format": "geotiff" in the request JSON, once the 2-D expansion grid is calculated, the grid is serialized as a GeoTIFF dataset and returned as raw bytes, instead of running the contouring algorithm.

Implementation Summary

• uses GDAL for writing the raster dataset; when building Valhalla, one needs to actively opt in to this feature by setting the cmake flag ENABLE_GDAL (OFF by default)
• raster data type: using uint16_t gives plenty range for distance and time metrics, so I decided to scale the values to seconds (which maxes out at ~18 hours) and 10 meter steps (~650 kms)
• each metric gets its own band
• the data grid has an immense padding, which leaves more than 50% of cells never reached by the expansion (in most cases probably more than 80% though), so the final raster is truncated to the minimum extent that actually contains values not equal to the set max value, plus just a little padding that reassures users we didn't accidentally cut off part of the grid 😅

For more info, see the initial discussion: #4581.

TODO

There are still one or two things left to do:

• figure out a way to return the file buffer as a string without copying it
• find out why raster values in the added tests are unexpectedly high (probably related to type casting)

Future steps

This is a basic first step, but it doesn't have to be the end of it. One could

• add color information for renderers by making use of color tables (I have fiddled around with it but haven't gotten far 😅)
• add some more metadata that can be useful for the ouput interpretation, e.g. about the snapped locations (analogous to show_locations)

Tasklist

• Add tests
• Update the docs with any new request parameters or changes to behavior described
• Update the changelog

[chrstnbwnkl]

be prepared to see plenty of these... I'm open to any suggestions that reduce these wherever possible

[chrstnbwnkl]

tyr has no way to maintain state, so thor_worker_t will hold the geotiff driver and pass an opaque pointer to it to the serializer function (note that GDAL is not thread-safe)

[nilsnolde]

great stuff, thanks!

not sure I'll join tmrw for the meeting so I left some comments here. maybe there's some way to hide the gdal headers in the implementation instead of exposing them in our headers. anyways, kevin is the master pimpl'er here :D

[nilsnolde]

maybe @dnesbitt61 you want to look at this too, kevin mentioned you had this idea before too:)

[nilsnolde]

so it seems debian & fedora based distros install gdal headers to /usr/include/gdal/ while pacman/arch/pkgbuild, brew & vcpkg install it to /usr/include/ directly. while I'd more agree with the former pattern (gdal has tons of installed headers), the latter one is coming from gdal's own cmake. I wouldn't really like to hack the cmake cxx/c flags for gdal. but maybe I'm not quite at full cognitive height anymore.. I asked upstream: OSGeo/gdal#9276

[nilsnolde]

yeah, ubuntu packaging messes up the .pc file: OSGeo/gdal#9276 (comment) nope, got fixed in gdal 3.8.0. anyways, let's then use cmake's find_package

[nilsnolde]

uh oh, windows is failing with some msvc specific stuff 😨

[chrstnbwnkl]

Is tidy hallucinating or am I?