MultiModal and NationalRail UK64

Applications
#103

Over the last few days I’ve changed the internal data structures and the corresponding code quite a bit to shift more of the logic from the QML/JS part to the individual, API specific, Python modules.
This was meant to untangle the mess MultiModal has evolved into over the years, starting with only one data provider and adding layers of exceptions upon exceptions to adapt to now 3 completely different APIs in the UK and 2 in Germany all using completely different technologies (Json, SOAP, XML, …).

The real challenge turned out to be finding a default colour for bus services (UK + Germany) and trams (Germany).

Traditionally MultiModal used Theme.secondaryHighlightColor as the background colour of the bus rectangle but I would like to get rid of yet another exception (as the value is not available in Python) and determine colours solely inside the Python modules.

Any ideas for a colour value that would be used for bus services and (different one?) for tram services if there are no line specific colours defined?

image
image1080×2520 275 KB

1 Like
#104

Cool news!

The generic colour Red for Tram seems common in Germany. The Buses in Berlin/Brandenburg are purple. Ferries are light blue in Berlin/Brandenburg. I believe the Buses are Blue in Munich.

An overview of the Berlin (up to 35 km outside the city) network: https://www.bvg.de/dam/jcr:60a89e3b-f88d-4d48-b8a6-98ab340ada05/S+U-Bahn_12_2021-Internetversion-BVG.pdf
Which comes from:
Netzpläne & Liniennetz für den ÖPNV Berlin | BVG

Some cities, like Cologne have complete colour coded Bus plans. But I’m not sure how common that is. EDIT, it’s the rule.

For BVG/VBB, Ferries light blue, Buses Purple, Trams red, I’d say if the color isn’t otherwise available. In the example you gave, you have the color for a bus line seemingly correct from the api?

#105

On second thought, If ONLY the trams don’t produce unique color values, then the tram logo on grey is just fine!

Just looking at the VBB results:

"line": {

    "type": "line",
    "id": "m8",
    "fahrtNr": "6479",
    "name": "M8",
    "public": true,
    "adminCode": "BVT",
    "productName": "Tram",
    "mode": "train",
    "product": "tram",
    "operator": {
        "type": "operator",
        "id": "berliner-verkehrsbetriebe",
        "name": "Berliner Verkehrsbetriebe"
    },
    "symbol": "M",
    "nr": 8,
    "metro": true,
    "express": false,
    "night": false,
    "color": {
        "fg": "#fff",
        "bg": "#EE7203"
    }

},

That bg value is the M8 orange for the M8 Tram in Berlin. The fg value is the Tram Red.

#106

I would prefer something that is not too distracting if used for a transport mode vs. individual lines e.g. I would try to avoid creating a “wall of red” when displaying bus stops.
That is also one of the reasons I opted to use generic “grey” for mainline trains plus as fallback value if no colours are specified for individual subway/s-bahn lines.

I opted to use the transport.rest DB API instead of VBB because of the different numbering scheme they use for stop points which would make it impossible to route between DB stations I already have stored locally and VBB stations provided by the API.

1 Like
#107

I’m happy with grey for uknown. Tram / Bus logos with color are sufficient, I think

And that’ll cover rail travel in most of europe :slight_smile:

I’ll go have a look if I can scrape you a table of colors together :slight_smile:

#108

There are open data sets here:
https://www.opendata-oepnv.de/ht/de/datensaetze?tx_vrrkit_dataset[action]=dataset&tx_vrrkit_dataset[controller]=View&tx_vrrkit_dataset[filter]=liniendaten&tx_vrrkit_dataset[key]=group&cHash=d4cbad7b6147b846e12b2e707a6bdf58

I’m looking through them as I have time. EDIT, it’s a mess. Be easier to scrape.

#109

I’ve just implemented generic lookups in the EFA and Hafas (XML) backends to see if anyone provides line color. Nope. In hafas there ‘was’ a color parameter for Line which seems to have entered and left just as quickly circa 2011.

Derhuerst https://github.com/derhuerst/vbb-line-colors/blob/master/index.json

I’d use these as a reference. I’ll try to scrape up more from the Hafas and EFA sites. There are some more modern (json) based ones which may have more information…

#110

When you take a look into the code, especially dbahn.py you should be able to see all the line colours I’ve added already. Most of the time I just screen-grabbed them from the home pages of the respective transit agencies as this seemed to be quicker than trying to find them in any sort of machine readable form :slight_smile:

On another note, should you stumble upon a list of VBB/BVG stops/lines that is compatible with the DB numbering scheme (e.g. 732623 for Eberswalder Str.) as used on v5.db.transport.rest I could add them to the local database.

#111

Yeah, I’m beginning to get that feeling. Since there’s a ‘german language’ thread, I asked for opinions there to see if a consensus or some expertise comes to light from the ‘native’ users.

Between Federalism and private companies (EFA, HAFAS) keeping apis proprietary, it’s a mess. I was about to start an essay, but I’ll see if I can just get the DB binary interface to spit out everything VBB :slight_smile:

EDIT. If you’re using the deutsche bahn interface, VBB is redundant!

#112

Without getting into too much detail, there is a central registry of the country wide codes. All systems in germany are coupled to delphi and the ids of all stops use DIHDs in that central db . I have that list as a csv. It’s 138 mb in size (you can make an account and query it https://zhv.wvigmbh.de).

That DIHD format:

de:07334:1736:2:22

Now, that doesn’t help us except that we also have lat/long. So I could map that. On the other hand, you don’t want to distribute that much information, I think?

#113

Thank you, I will take a look.

I’m not sure if in times Sailfish phones come with 6 GB RAM and 128 GB storage, 130 MB would not be just more than an irrelevant blip. :slight_smile:

1 Like
#114

It’s only 19 mb compressed :slight_smile:

#115

So, comparing the data from the central registry and the data from VBB, it looks like VBB is using the Delphi ids directly:

grep Strausberg,\ Lustgarten zHV_aktuell_csv.2022-05-18.csv 

"263523";"S";"de:12064:900320025";"de:12064:900320025";"Strausberg, Lustgarten";"52,576202";"13,880868";"12064472";"Strausberg";"";"";"Served";"Unknown";"";"VBB";"-";"";""

 grep Strausberg,\ Lustgarten 2021_03_UMBW.csv 

Strausberg, Lustgarten;Strausberg, Lustgarten;Bauwerk;1367;;13,880868;52,576202;320025;900320025;

central “de:12064:900320025” and local 900320025

EDIT: the dbahn has 000738598:

Lustgarten,+Strausberg@X=13880801@Y=52576163@U=80@L=000738598@B=1@p=1652727942@

So, what we have in common is not even lat/lon. sigh.

#116

What one could do is take the coordinates of all the stops e.g. in Berlin and then use the DB API itself to look up all the stops near the corresponding positions, then we should be able to compile a list of all the stops with their correct DB IDs.

https://v5.db.transport.rest/stops/nearby?latitude=52.541023&longitude=13.412154

But I guess this would have to be done slowly over hours to not overwhelm the API endpoint and end up being blocked or something :grinning_face_with_smiling_eyes:

1 Like
#117

public floggings of all involved is more like it :slight_smile:

I have to do some python/ffmpeg debugging (apps in store already no longer running in sailjail) … but when I’ve go the logs posted I’ll look a scraping.

1 Like
#118

Can we get the source code to build the app ourself or contribute?

1 Like
#119

It’s a QML + Python app, so everything should be contained inside the RPM already.

#120

Somehow urllib.request.urlopen(req).read() seems to take ages to finish since the last update, at least when I’m on mobile data.
Looks like some kind of weird DNS issue that only affects this Python library, because opening the same url with “curl” seems to be fine.

Should someone encounter the same issue, adding the IP addresses of the individual API endpoints to /etc/hosts seems to fix this:
34.253.134.204 lite.realtime.nationalrail.co.uk
104.16.101.13 api.tfl.gov.uk
137.135.131.93 api.tfgm.com

EDIT:
This issue seems to be related to VoLTE !

I can easily replicate it:

  1. VoLTE enabled - API calls are slow
  2. VoLTE disabled - API calls are quick
  3. VoLTE enabled again - API calls are slow again
#121

That is not really the same thing.

1 Like
#122

I’m developing on my phone so I’m literally rsync-ing the /usr/share/harbour-multimodal/ directory into my rpmbuild path when packaging. The only thing you’re maybe missing is the spec file, I’m happy to pm it to you if you like or I put it into the rpm on the next build.