GitLab

See https://phabricator.kde.org/T12200

Ensure that OpenSSH and Java are included in the image, to allow for it to be used by Jenkins to generate the necessary binaries and *.deb files on the Binary Factory (for deployment into production)

Also, clean our apt cache afterwards to keep the image size down

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"

This should help in case there is no suitable PPA for Tirex for the version
needed on the server. The part we need of Tirex is ultimately just a Perl
script anyway, the compiled parts are only needed for Mapnik integration
that we are not going to use.

Those are only needed once on initial setup and could be used offline, but
with this direct execution on the production system is also possible.

That's what is being used on the new maps.kde.org server.

Instead of extracting all files in the ZIP archive extract only the
KML file into a QByteArray and feed it into the parser.

As there are no longer any temporary files to clean up, KmlDocument is
no longer needed, GeoDataDocument is sufficient.

This also avoids an error in the thumbnailer, which fails when it
tries to geocast the KmlDocument to a GeoDataDocument.

BUG: 428437
CCBUG: 420089
CCBUG: 416925

As the filemanager is also used from non-interactive contexts, a message
box is a no-go.

Interactive applications can connect to the fileError signal. This is
done for both marble-qt and marble-kde.

BUG: 416925
CCBUG: 420089

The `FileManager::fileError` signal is emitted when the file could not
be loaded. Instead of waiting for the 5 second timeout for each erroneous
file, immediately return.

The FileManager class is accesible from the public
`MarbleModel::fileManager()` method.

The `fileError` signal is useful to wait for a file to have loaded, it
is the error counterpart of the `fileAdded` signal.

This avoids including a non-installed header file here, which broke the
build for external users.

Those are extremely rare, and obviously have no visual impact in Marble,
but they do contain valuable information for other users of the vector
tiles.

An example are railway=platform_edge segments of railway platforms (and
that's actually the only case affected by this I have found so far), and
that's about 1.5k elements for all of Germany, so not an amount that would
matter in the big picture.

We need to consider the UTF-8 encoded string length here, which can differ
from the QString length previously used. In most cases the difference isn't
relevant, but I have encountered two tiles so far where those values not
only differed, but ended up on either side of the 250 character limit here.
If that happens the string table in the o5m decoder when reading this ends
up in an inconsistent state, and produces spectacularly messed up tags.

While at it, also sharpen the asserts here, violating either of those would
produce invalid o5m output.

There seems to be the assumption in a number of places here that a single
64bit number is enough to identify any OSM element. This however isn't
entirely correct, as OSM nodes, ways and relations use separate identifier
spaces, so we either need to infer the type from context or explicitly
carry it along next to the number. This wasn't done for non-geometry
relation members however, resulting in all member types ending up as "way"
when serialized back to o5m, which quite thoroughly corrupts those
relations.

This change does the bare minimum to fix this specific issue, API not
relevant for this is adjusted to keep the old broken behavior.

With relation member types preserved we however hit a subsequent problem
in the o5m encoder, which needs to track differential id encoding state
separately per type.

This affects a very small amount of nodes that are not currently rendered
by Marble (e.g. various types of free-standing ticket vending machines).
With this change those are also included in the generated o5m tiles, which
matters for other users than Marble (and presumably Marble would want to
show those properly eventually too).

This also require a minor change to Marble's style selection, as unknown
nodes were shown with the default style (a yellow dot) so far, which is
undesired I assume (but made it very easy to verify this is only a small
amount in total).

This was failing on highway=* areas so far, treating them as (open) ways
and badly messing up clipping as a result of that. This is visible in the
old tiles as well, and affects both Marble's rendering as well as geometry
reassembly.

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.