- 19 Oct, 2020 4 commits
-
-
Volker Krause authored
-
Volker Krause authored
-
Volker Krause authored
-
Volker Krause authored
-
- 18 Oct, 2020 36 commits
-
-
Volker Krause authored
-
Volker Krause authored
Necessary to install KOSMIndoorMap as a shared library as well.
-
Volker Krause authored
In preparation of installing this as a shared library.
-
Volker Krause authored
-
Volker Krause authored
Now that this is in its own repository, there no little point in supporting an optional build.
-
Volker Krause authored
-
Volker Krause authored
-
Volker Krause authored
Prepares this for being installed as a shared library.
-
Volker Krause authored
-
Volker Krause authored
Needed for KDE Itinerary to preload map data for an entire trip.
-
Volker Krause authored
-
Volker Krause authored
We need that in more places.
-
Volker Krause authored
As usual it's only ever a question of time until you find a bit of OSM data that violates whatever assumptions we make here.
-
Volker Krause authored
We now look at building:levels first, and interpret an also present level tag as building:min_level in that case. That's not how this is supposed to be used IIUC, but it reflects how this combination is used in reality nevertheless.
-
Volker Krause authored
This now also works with OSM::TagKey, not just const char*, and in any arbitrary mix of those two.
-
Volker Krause authored
Useful now that we only see the processed overlay in the normal view.
-
Volker Krause authored
-
Volker Krause authored
-
Volker Krause authored
The platform ones can still be improved by using full edge/track geometry probably, but this is already better than the old approach.
-
Volker Krause authored
-
Volker Krause authored
-
Volker Krause authored
Provides the type erasure like features of OSM::Element for synthetic elements used e.g. in overlays as well.
-
Volker Krause authored
This fixes the remaining issue in the Leipzig test case.
-
Volker Krause authored
This should work now as the model has been ported to the new platform finding code.
-
Volker Krause authored
This fixes the detection issue for platform 4.
-
Volker Krause authored
With the multi-track element support this now starts to work mostly ok, the remaining issue on the S-Bahn track 3 has been fixed upstream in OSM and should work with the next OSM data update.
-
Volker Krause authored
If they are broken apart very in a very fine-granular way, we might only be able to assemble things at the very end, and with trying all possible combinations.
-
Volker Krause authored
For a single track split the previous approach was still somewhat working, for the triple or quad split found in some places it wasn't working at all anymore though. So we now properly (and when needed assemble) all track fragments. Sooner or later we would probably have needed that anyway (and same for edges), as we otherwise can't do a proper vehicle layout overlay.
-
Volker Krause authored
Will also be needed for multi-element tracks/edges in the platform model.
-
Volker Krause authored
-
Volker Krause authored
The new system seems strictly better than the old one by now, even if it still fails in a few complex cases.
-
Volker Krause authored
Mainly missing cases for connected areas/edges/tracks.
-
Volker Krause authored
In split area scenarios it can happen that a merge only becomes possible after two subsequent elements have been merged. So try this until nothing else can be merged anymore.
-
Volker Krause authored
Driven by a table now, so it's the same for all modes.
-
Volker Krause authored
This is a complex scenario with platform edges and areas split into two parts on level 1. We don't handle this correctly in all cases yet (tracks 12, 13, 17 and 18a are still duplicated), but it's not completely horrible anymore with the recent changes.
-
Volker Krause authored
This also fixes a pretty severe bug in Element::operator!= not working at all so far. As a side-effect we get the (presumed) loading ramps in Gare de Lyon detected now, which technically is correct, those a distinct platforms. Before looking for a post-processing filter for those, let's first see if we can fix that in the OSM data.
-