GitLab

The previous approach put coordinate pointers into the point structures of
the clipper lib. This worked in most cases, but as there are no guarantees
on point references remaining valid, the clipper lib ended up swapping
values of points in some cases, breaking our coordinate references and
subsequently losing the attached OSM data. While this is usually not a
problem for a random node, it could also happen on the closing node of a
polygon, causing it to no longer be closed and confusing the hell out of
the geometry reassembly code.

The new approach tracks this outside of the clipper lib with a map on the
integer coordinates (and thus avoiding floating point number comparison
issues). This also allows us to roll back a bunch of Marble-specific
changes to the clipper code.

The check in there fails if the protobuf headers are found, but protoc is
missing and pretends protobuf is functional nevertheless. Additionally
some Debian variants are splitting those two parts in different packages
without adding a dependency between them. So on those systems we can end
up with build errors due to such a partial setup without CMake catching
this.

The whole concept is almost unused and there's no point in having it there but empty

See also https://phabricator.kde.org/T13553

Besides not losing tags on such nodes, this also retains OSM ids in all
cases now, which simplifies geometry reassembly considerably, as this
gives us a lot fewer nodes to consider for merging.

This matches what's currently on maps.kde.org.

Also, start to document the setup.

This relies on being executed during plugin loading, but in a static build
it's either executed too early when the called code isn't ready yet (which
crashes), or not at all.

This can probably be done nicer by refactoring this to avoid relying on
static construction, but given this is only actually used in one single
place handling this manually for the Tirex backend is good enough.

The surrounding code handles this just fine, just the checking code didn't.

Needed for building this for Ubuntu 18.04, which is what is running on the
maps.kde.org server.

The tile generator doesn't need this, yet this is created, and fails to
load with a reduced set of plugins.

Also, prepare this for static plugins.

Adapt to API changes

This does happen around the poles, and would crash generating a tile
covering that area.

This is useful for testing/profiling the processing of one specific meta
tile under easier to control conditions.

For this we need to split a meta tile into a number of sub-blocks and
traverse them in the right order to avoid loading input data multiple
times.

This allows us to tweak the load size for z13 in a way that is good enough
for live generation as well.

Due to the use of sub-processes during the tile generation we re-enter the
event loop, and thus might receive another socket notification while the
previous one is still being processed.

This is using a slightly weird setup with a 1:N UDP socket connection
for distributing work to multiple render processes. Qt's UDP code doesn't
really get along with that, and over time degenerates to only one of the
backends still being able to communicate.

To address this, bypass Qt entirely for the communication and do this
manually. That reduces portability, but that doesn't matter given that
Tirex and mod_tile aren't more portable either.

mod_tile doesn't trigger a re-render when encountering those, but just
throws an error, so avoid ever getting into that state.

This is mostly copy/pasting of the relevant code from cachetiles.cpp,
but this now actually allows to request on-demand created o5m tiles
via mod_tile, assuming the setup this code expects is all there.

This did expose a limitation of mod_tile, which assumes file extensions
to only contain lower-case letters, and thus chokes on our use of "o5m".
This can be worked around though by a simple rewrite rule.

This produces textual dummy content still, but it demonstrates the entire
roundtrip from mod_tile -> Tirex -> our code -> HTTP response with the
right content now.

This implements enough infrastructure to receive render requests coming
in via Tirex and mod_tile. We can only answer by an error message so far
though.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

QT_STRICT_ITERATORS do not work on vs compilers.
Missing ZLib includes for osm runner plugin.