MultiModal and NationalRail UK64

Applications
#63

Does this exclusively happen the first time after you start the app and then, after a reload, this issue disappears completely until you start the app again?

There is nothing in MultiModal that should be able to actively reorder bus stops (as this function would not make much sense in the first place) also the “time to station” seems to decrease sequentially in both screenshots indicating it’s probably not just an visual glitch with the QML list itself.

But I will check the TfL API response should I be able to replicate this issue.

1 Like
#64

Yes it seems to happen after start up but I’ll keep an eye on this. I tend to be using Wi-Fi at home when first using the app then mobile data as I walk to the departure stop so could there be an issue with the cached data from WiFi and mobile data? I note that when you look at the route information it seems to show timings and stops based on where the bus is now and shows a number of stops from that point. The stops shown will change as the bus gets closer.

It would be odd for the App to be able to re-order stops and the source data could be at fault.

I’ll see if this persists and thanks for looking at this.

#65

I’ve been playing around with the transport.rest API lately and routing looks quite promising:

multimodal01
multimodal011080×2520 432 KB

#66

Indeed! Is this still prototyping?

In the meantime I’ve picked up Fahrplan which is using numerous binary and xml interfaces. Those won’t be available for ever. The old parsers which I could update (but two) I’ve rescued, but I really should look at implementing transport.rest.

Or just be lazy and let you do the work :slight_smile:

#67

At the moment the only thing preventing me from releasing an early version is how woefully slow and inefficient it still is.
I’m pretty confident all the issues can be optimized away, I just have to find the time to actually do it.

#68

I just looked at the wrappers (a subset of Public Transport · GitHub) and those are all hafas clients for the mobile versions of the respective services. I know that the binary endpoints of hafas (deutsche bahn for instance) are much faster than the xml endpoints (austrian for instance). But I would think the rest api’s could be as fast as the binary. Certainly easier to parse :slight_smile:

What are the city of london’s api’s based on? I think they are more modern than hafas/efa ?

I’'m looking at the endpoints the need fixing and will snoop about looking at those that have rest endpoints.

#69
#70

I just looked at the Danish hafas endpoint (one of the last ones I had left) https://mobil.rejseplanen.dk/bin/iphone.exe

That’s all hafas in js. When I have some time I’ll compare that to transport.rest.

I’m looking at building a hafas json parser (in c++) since I already have 2 json based parsers so much of the ground work is done.

#71

The inefficiencies in my transport.rest back end are entirely up to me, e.g. making 10 consecutive requests per route and waiting for them all to finish is just not a very efficient way of doing things. :grin:
I just wanted to have something that would prove the concept and then decide from there what to do next.

#72

Ah, got you. I’m just happy to get results at all :slight_smile: It’s a bit of work but there is some assistance to be had for the c++ end of it from the kde folk: src/lib/backends · master · Libraries / KPublicTransport · GitLab

#73

I’m happy to have ported MultiModal to Python at some point an I’m not looking back :grinning_face_with_smiling_eyes:

#74

Yeah, it’s faster and in a sense more sustainable. But, I thought I’d resurrect Fahrplan, since it’s the best tool for the job in Germany. I’m thinking of a fast and dirty QML only mockup. Easier to find help maintaining it :slight_smile: hmmmm.

#75

multimodal03
multimodal031080×2520 421 KB

Loading additional stuff like calling points etc. is now done dynamically, depending on which journey is selected, making everything much faster.
Sadly, I also managed to break TfL routing in the process so this will take a bit longer than anticipated.

#76

I’m open for ideas how to improve MultiModal to make it more usable in Germany as well.
Version 0.60 should now be available on OpenRepos.

#77

Heh. It may soon come the day when the old api’s from the DBahn are no longer available, and we all use MultiModal. Did you or will you publish your source? I’d be more than happy to to contribute since I’m staring at the apis all the time.

I’ll try out the latest version. THANKS!

#78

Well, it’s all just QML and Python so all you’re getting is the source code when you install MultiModal :slight_smile:

#79

Yes, it’s a noarch RPM on OpenRepos containing all the source code.

#80

ah. duh. Well, I’m sort of a fan of doing development on a git backend. Still, right you are :slight_smile:

#81

Ok, just tried it out. It’s nice an quick though I was confused at first by location being on but not actually getting a fix? I closed the app, turned on location and ensured I got a fix with pure maps and it worked. It looks like only S-Bahn connections were being searched for (Tram line stops weren’t being found).

One completely unrelated question. I noticed you install a scalable svg. Is there a ‘proper way’ to do that in the spec? Or just copy in place?

#82

Yes, the data set for Germany only contains mainline train stations and S-Bahn stations at the moment.
I have to find and import all the BVG stop points to make it work with trams and buses in Berlin.