I'm often using trains and public transport. For Germany, this often results in using "Deutsche Bahn". The Deutsche Bahn offers three possibilities to buy tickets: 1. online, 2. via a counter (in person), 3. via ticket machine. Additionally, pulic transport in particular often offers tickets via ticket machines only. For "Deutsche Bahn", I prefer the third, since it is the only fully anonymous variant. However, I have no possibility to get these data into KDE Itinerary (at least no that I know of). Scanning the printed ticket or the preprinted schedule and recognize it via OCR etc. seems absolutely complicated. However, for most German transportation systems (and other countries) the great Öffi app exists (https://oeffi.schildbach.de/) or, with the same backend, Transportr (https://transportr.app/). It is simple to reproduce an arbitrary schedule with this app. What do you think of implementing a connection between Öffi and KDE Itinerary? With that, I can share a schedule calculated by Öffi with KDE Itinerary so that it imports it. SOFTWARE/OS VERSIONS Android: 21.08.1
If I understand correctly this is about adding a train connection to the timeline manually, as you don't have a PDF ticket that can be imported automatically? That could be implemented even without using any of the mentioned external apps I think, we have access to the same data that those are using. That is right now used for example for selecting an alternative in case of a missed connection or for determining delays/disruptions for existing connections.
(In reply to Volker Krause from comment #1) > If I understand correctly this is about adding a train connection to the > timeline manually, as you don't have a PDF ticket that can be imported > automatically? Yes, exactly that. > That could be implemented even without using any of the mentioned external > apps I think, we have access to the same data that those are using. That is > right now used for example for selecting an alternative in case of a missed > connection or for determining delays/disruptions for existing connections. If this works, too, it can be a viable solution either. The other apps already have nice GUIs for searching/choosing the correct trains/choosing the correct service provider, so it may be simpler. These are some example data from Öffi when I "share" the connection: ``` IC 2273 ➝ Berlin Südkreuz ab: 02.10.21, 18:19 7 Berlin Gesundbrunnen an: 02.10.21, 18:23 1 Berlin Hbf ICE 1715 ➝ München Hbf ab: 02.10.21, 18:30 2 Berlin Hbf an: 02.10.21, 23:04 20 München Hbf 10 Minuten (182m) Fußweg nach München Hbf U 2 ➝ Messestadt Ost ab: 02.10.21, 23:14 München Hbf an: 02.10.21, 23:23 München-Giesing 2 Minuten (41m) Fußweg nach München-Giesing O7 ➝ MVG-Museum ab: 02.10.21, 23:33 München-Giesing an: 02.10.21, 23:38 MVG Museum ```
(In reply to ci3nte from comment #2) > > That could be implemented even without using any of the mentioned external > > apps I think, we have access to the same data that those are using. That is > > right now used for example for selecting an alternative in case of a missed > > connection or for determining delays/disruptions for existing connections. > > If this works, too, it can be a viable solution either. The other apps > already have nice GUIs for searching/choosing the correct trains/choosing > the correct service provider, so it may be simpler. We have most of those building blocks as well already I think, either in Itinerary or KTrip, but integration with external apps is interesting in its own right nevertheless. I didn't know Öffi has a share feature for example, that could indeed be something for us to consume. Best case would be a machine readable format including station identifiers and geographic coordinates, so we don't have to re-query those ourselves. Something to discuss with the Öffi/Transportr people :)
Done for Transportr (https://github.com/grote/Transportr/issues/787). Öffi has no bug tracker (or at least I did not found one).
https://invent.kde.org/utilities/ktrip/-/issues/27 goes into a similar direction. Perhaps we can use the calendar as an intermediate for exchanging data? Trip connections should model well as calendar events and we can include more metadata in custom fields, much like the existing calendar integration in Itinerary
(In reply to Nicolas Fella from comment #5) > https://invent.kde.org/utilities/ktrip/-/issues/27 goes into a similar > direction. > > Perhaps we can use the calendar as an intermediate for exchanging data? Trip > connections should model well as calendar events and we can include more > metadata in custom fields, much like the existing calendar integration in > Itinerary Assuming Itinerary would have the ability to create a new reservation element from a KPT Journey, KTrip -> Itinerary integration should be fairly straightforward, via KPT's JSON serialization. Whether we then send this through the calendar, the clipboard, an Intent or ApplicationLauncherJob is secondary I think, as Itinerary routes all that through the same unified importing code anyway. Itinerary -> KTrip should be even easier, as Itinerary already holds KPT Location and/or Journey objects for basically everything in the timeline, so this is mainly a matter of defining use-cases where we'd want that. With KPT gaining support for individual transport and inter-modal routing we also should discuss integration regarding that, e.g. for sharing user preferences (has a bike, can drive a car, etc) and for state (where did I park my bike/car on the way out so we route back there on the return journey). But that's getting off-topic here... Independent of that, I do agree that we should expand the calendar integration :)
Just to add an other case were manual data import is needed: I have a season ticket and don't buy "normal" tickets consequently I also don't have PDF tickets, reservation e-mails etc. Without having a possibility to import trip data from other apps like (most obvious and easy) KTrip, but also maybe via the "share" function of eg. Öffi, "DB Navigator" and apps from local transport services, KItinerary is useless for me at the moment. :-( But I would really like to use it!!! BTW Some of the mentioned apps (eg. "DB Navigator") are also able to create calendar entries this would be another way to exchange data beside the "share" function. On a side note I also want to mention another interesting way (at least for German trains) to import trip data if you are already in the train: the APIs of iceportal.de and zugportal.de (If you want to learn more about it feel free to get in touch with me on Matrix @jlskuz:kde.org)
(In reply to Julius Künzel from comment #7) > Just to add an other case were manual data import is needed: I have a season > ticket and don't buy "normal" tickets consequently I also don't have PDF > tickets, reservation e-mails etc. Right, we got similar feedback from BC100 users and DB employees. > Without having a possibility to import trip data from other apps like (most > obvious and easy) KTrip, but also maybe via the "share" function of eg. > Öffi, "DB Navigator" and apps from local transport services, KItinerary is > useless for me at the moment. :-( But I would really like to use it!!! Since a bit more than a week this is actually mostly implemented in Itinerary (think "embedded KTrip"), it's not yet activated in the normal builds though as it depends on the not yet released kirigami-addons module. > BTW Some of the mentioned apps (eg. "DB Navigator") are also able to create > calendar entries this would be another way to exchange data beside the > "share" function. That's a good idea, we can already import from the calendar on Android, but so far only events that were added by the KMail plugin, not those of other apps/services. > On a side note I also want to mention another interesting way (at least for > German trains) to import trip data if you are already in the train: the APIs > of iceportal.de and zugportal.de (If you want to learn more about it feel > free to get in touch with me on Matrix @jlskuz:kde.org) Great idea as well! Onboard APIs have been on the list of things to look at, but so far mainly as an additional data source for delay/disruption data. Using that for adding data in the first place makes a lot of sense. There has been some discussion on collecting and documenting these APIs together with other interested parties: https://github.com/derhuerst/live-icomera-position/issues/3 / https://github.com/public-transport/transport-apis/issues/31
(In reply to Volker Krause from comment #8) > > Without having a possibility to import trip data from other apps like (most > > obvious and easy) KTrip, but also maybe via the "share" function of eg. > > Öffi, "DB Navigator" and apps from local transport services, KItinerary is > > useless for me at the moment. :-( But I would really like to use it!!! > > Since a bit more than a week this is actually mostly implemented in > Itinerary (think "embedded KTrip"), it's not yet activated in the normal > builds though as it depends on the not yet released kirigami-addons module. Is it activated, yet? At least, I cannot find it in the app and there should be several KDE releases in the meantime. Or do you have an ETA? Would be really nice!
(In reply to ci3nte from comment #9) > Is it activated, yet? At least, I cannot find it in the app and there should > be several KDE releases in the meantime. Or do you have an ETA? Would be > really nice! It's not activated unconditionally yet as the kirigami-addons module is still not available on all platforms. On Android you can test it already after activating the developer mode (https://community.kde.org/KDE_PIM/KDE_Itinerary#Switching_KDE_Itinerary_to_Development_Mode).
Nice! Though, it has take I while for me to find the button (after activating the developer mode) since I searched in the left menu only (near Scan and Paste). Also, the UI looks strange on a small screen. See the attached screenshots. (Also, just as a question that actually doesn't belong to this bug: Is there a visual or haptic indication if a barcode was recognized by the builtin scanner but not able to import to Itinerary?)
Created attachment 149047 [details] Datepicker.png
Created attachment 149048 [details] search-cursor.png Initially, there is a magnifying glass shown with the text "Suchen" besides it. As soon, as I click on it, the magnifying glass disappears, but the cursor remains on the position where the "S" from "Suchen" was.
Git commit 86282a05433ae59c1e8c72a52cfefa450ec61b1a by Volker Krause. Committed on 22/05/2022 at 08:04. Pushed by vkrause into branch 'master'. Use the latest kirigami-addons for Itinerary The last release is a year old and lacks the Android platform integration. M +1 -1 kde/applications/itinerary/itinerary.py https://invent.kde.org/packaging/craft-blueprints-kde/commit/86282a05433ae59c1e8c72a52cfefa450ec61b1a
(In reply to ci3nte from comment #11) > Also, the UI looks strange on a small screen. See the attached screenshots. Indeed, and this is not how it's supposed to look like, you should get the native Android date/time controls there instead. This should be fixed in the next update. > (Also, just as a question that actually doesn't belong to this bug: Is there > a visual or haptic indication if a barcode was recognized by the builtin > scanner but not able to import to Itinerary?) Yes, see the screenshot in https://volkerkrause.eu/2022/04/02/kde-itinerary-february-march-2022.html, which shows exactly that situation.
22.08.0 has this activated unconditionally on all platforms.