v1.1.0

This is a big update with a lot of quality-of-life updates especially for map matching large floating car data sets.

• We updated several third-party libraries; libosmium to v2.22.0, Expat to version 2.7.1, and Boost to version 1.88.0; we also now removed protobuf from the repository as it was no longer referenced.
• The update to Boost 1.88.0 fixed an issue that prevented to use newer Clang compilers, so we can build against Clang 20 now, see boostorg/thread#402, however, the AppImage release contains a GCC build.
• We also updated GCC to 15.1.0 and CMake to 3.31.6, and on Windows, we used the newest Visual Studio version 17.14.0.
• We now build the software completely statically linked on Linux, in the hope that this solves issues with the AppImage now working on other systems than the target system it was compiled for, due to glibc incompatibilities.
• We also use a more recent appimage-tool now that uses a new runtime which should also improve compatibility of the AppImage and also may render libfuse2 obsolete, see AppImage/AppImageKit#877 (comment).
• We changed the official Dockerfile to incorporate the fix discussed in #9, thanks to @mschrader15. The entrypoint has changed, the application is now directly called instead of a sub-shell. The official Docker image at addy90/map-matching-2 was updated accordingly.
• We refactored the track importer functionality to accommodate for further changes.
• With this refactoring, we added two new filter methods that can filter tracks during import:
  • A new split-time method that can split tracks into multiple tracks when the difference between two point timestamps exceeds a defined value. This is an important setting for large floating car data where multiple individual tracks are aggregated under the same id. This method is able to split the individual tracks based on a difference between two points, for example, when you define 600 seconds, a track is split into two tracks when there are two points that have a time difference of at least 10 minutes. Only works for tracks that are imported with a time information, of course.
  • A new filter-polygon method that only keeps tracks that are either within (i.e., in practice covered-by, which means the border counts, too) or intersect (i.e., within or partially overlapping) a given bounding-box or complex polygon. A bounding box can be defined as WKT BOX (10 20, 40 50) with the lowest x, y and highest x, y coordinates, and a complex polygon (which needs to be closed and counter-clockwise defined) can be defined as WKT POLYGON ((30 10, 40 40, 20 40, 10 20, 30 10)) with a list of x and y coordinates. The filter-method can be selected so that only tracks that completely lie within the given polygon or bounding box are kept, or all tracks that lie within or intersect the border, i.e., intersect contains within, so only tracks that completely lie outside the polygon or bounding box are filtered out. This setting is especially useful for when from a large floating car data set, only a specific region is of interest. It works in combination with split-time so that first the tracks are split and then, in case a split part is kept by the filter, that part is kept, while the rest is not. So first the splitting, then the polygon-filtering. Keep in mind that the filtering is done in the import-thread, not in the parallel matching threads, so you may not want to use very complex and large polygons, as these increase the time it takes to filter a track immensely; in these cases, we recommend to compute and use the convex hull of the polygon, or use a bounding box of the polygon, to not bottleneck the import thread.
• We now output the start and stop time of the track in the results, however, due to technical design decisions, the original time-zone is not kept and needs to be defined with the new export-time-zone setting, if the default system setting is not wanted. Alternatively, unix timestamps can be exported with the new export-timestamps setting. It is also possible to export all timestamps of all points of the track in a new column, check the columns setting in the help.txt. Of course this setting is only useful for tracks which have times, but it is still possible to match tracks without time-information, this has not changed. The output of the track times, however, can be useful for further analyses.
• We now sort points by timestamp with stable-sort so that points that have the same timestamp are not reordered anymore. This may slightly improve matching quality in such cases. Btw., the candidates export functionality also exports the time information now, see candidates-columns.
• We use eager-initialization of track metadata, such as segment lengths and azimuths, and we moved that initialization to a later step in the pipeline so that it is carried out only for the tracks that were not filtered out before, to address unnecessary computations.
• We also finally added general switches to disable all steps of trajectory-simplification and candidate-adoption with one setting.

Full Changelog: v1.0.11...v1.1.0