GitLab

That is, which individual transport options should be considered on the
first (access) and last (egress) leg of a journey. So far we always
implicitly assumed walking. Scenarios that are now also possible are e.g.
taking your bike and taking that with you on the train, or taking your car
to the station (and needing a place to park it there). Routing engines can
take all that into considerations, if we ask them to.

This is modeled based on OTP v2/Entur v3) but should cover the capabilities
of other engines as well.

This is only the request API so far though, support in any of the backends
is still missing, as is support for this in the result types.

On top of the list of path sections this computes relative turn directions
for adjacent sections.

We were already mixing stops/stations and general places in Location so
far, and we now also have to model dock-based and free-floating rented
vehicles there.

That is rental bikes, electric scooters or car sharing services. So far
we only parse rental bike data from some OTP variants.

Used in the map example to show line logos for lines departing from a
platform.

This is still missing merging and de/serialization support, but you can
already see results when using only a single backend that supports this.

Departure was always a poor name, given it is also used for arrivals.
Things got worse with this now also being used for intermediate stops,
which are both arrivals and departures at the same time. Finding a good
alternative name is tricky though, as many candidates are ambiguous
regarding stop locations ("stop", "halt", etc). Digitransit uses the
words "call" and "quay" to distinguish this, but while clear those are
rather niche terms. FPTF uses "stopover" for this, which seems like a
decent compromise.

This is only the first step in adjusting the entire API accordingly,
more classes will follow, while trying to keep source compatibility.

We can now trigger vehicle layout queries from QML and have the query
request show up in the right place in the backend. The next step is now
to actually implement the online query and result parsing.

This will eventually allow to select which backends to use, both via API
and for end users. So far this is just read-only information , more work
required to make this actually useful.

Didn't seem to happen automatically for pure QML usage (although I don't
see what would trigger this in the current examples).

Also add a pure QML test file to verify this.

One step further towards full QML API coverage.

Same as already done for the departure query model.

That still misses API to create and manipulate a departure request, but
for now I'm getting that from C++ anyway.

Summary: Move the type registration from Itinerary into a proper qml plugin so it can be used everywhere

Reviewers: vkrause

Reviewed By: vkrause

Differential Revision: https://phabricator.kde.org/D22411

This just contains barely enough data model and backend access code to
search for a journey between two locations. Most notably this still misses
a frontend API that hides the various low-level REST calls behind a
job-like interface.

This is prepared to eventually become a standalone framework, it's useful
beyond just this application.