Use libspatialjoin for geometric relations, drop Boost dependency

[patrickbr]

This PR uses libspatialjoin to compute the geometric relations. It also completely drops the Boost dependency from osm2rdf (osmium still requires boost) by replacing all geometric stuff with its functional equivalent from util. Additionally, the Bzip2-zipping is now done manually (it was done via boost filtered streams previously).

Everything compiles and seems to work. The E2E tests are still failing, mainly because the mechanism to capture writes to stdout does not work anymore.

It would be great if anyone could test this and give some feedback.

[lehmann-4178656ch]

Thanks for the work, some minor comments from just looking at the PR. Will test later.

[patrickbr]

Three notes on the option --add-hascentroid emerged after a short discussion with Axel:

1. I am against the option --add-hascentroid, and so is Axel. It should be the default behavior, maybe with an option --no-hascentroid to disable it.
2. It would be elegant to re-use the geometry object of points for their centroid.
3. A valid query would be: give me all objects whose centroid is in area X. This is not possible at the moment, because the centroids are never given to libspatialjoin for computation of the geometric triples. Problems I see with adding geometric triples for them: (1) sfCovers and sfCovers would essentially double in size, (2) all geometric relations are between OSM objects at the moment (in the triple chain osmobject hasGeometry geometry asWKT WKT, geometric triples are attached to osmobject), but for the centroids, we do not have a distinct OSM object, and the geometric relations would have to be between the geometry object and another OSM object / geometry object.

[patrickbr]

@lehmann-4178656ch, I have now fixed all the tests. I think this branch is now ready to be merged into master. We are already using it in production for the weekly TTL extracts.

[patrickbr]

Well, I made the centroid writing the default as a last-minute change, and now all the tests are failing again because of the centroid output. Will fix this.

[lehmann-4178656ch]

Thank you for this. I've added some remarks regarding the use of Dx and x<double>, these are not critical.

I'm having an issue trying to build this branch as the spatialjoin submodule fails:

-- Submodule update
Submodule 'vendor/spatialjoin' (https://github.com/ad-freiburg/spatialjoin.git) registered for path 'vendor/spatialjoin'
Cloning into '/app/vendor/spatialjoin'...
fatal: remote error: upload-pack: not our ref 43d5d781931d8f73e1820de0e11321fee75fd50b
fatal: the remote end hung up unexpectedly
Fetched in submodule path 'vendor/spatialjoin', but it did not contain 43d5d781931d8f73e1820de0e11321fee75fd50b. Direct fetching of that commit failed.
CMake Error at CMakeLists.txt:79 (message):
  git submodule update --init failed with 1, please checkout submodules

Following the link in the webui pointing at https://github.com/ad-freiburg/spatialjoin/tree/43d5d781931d8f73e1820de0e11321fee75fd50b results in a "Page not found" error

[patrickbr]

Sorry, my bad, I forgot to push the latest spatialjoin. It should work now.

I changed the usage of the templated geometry types to their typedefs everywhere as suggested.

[lehmann-4178656ch]

I've successfully build the docker container now. Thanks again!