If there is a ‘proper way’ I’m not aware of it yet
Ah, I pounded my way through the docks only to discern, in the end, that harbour wants a bunch of pngs anyway. Sigh.
Hmmm. I’m not sure what your approach is, but I just kicked the can, entering a place name that happens to correspond to multiple media (S-Bahn, Tram, Bus):
~/src/sailfish$ curl 'https://v5.db.transport.rest/locations?query=Hegermühle&results=3' -s | jq
[
{
"type": "stop",
"id": "8080680",
"name": "Hegermühle(Strausb.)",
"location": {
"type": "location",
"id": "8080680",
"latitude": 52.548799,
"longitude": 13.866733
},
"products": {
"nationalExpress": false,
"national": false,
"regionalExp": false,
"regional": true,
"suburban": true,
"bus": true,
"ferry": false,
"subway": false,
"tram": true,
"taxi": true
}
},
{
"type": "stop",
"id": "738597",
"name": "Hegermühle, Strausberg",
"location": {
"type": "location",
"id": "738597",
"latitude": 52.555766,
"longitude": 13.865367
},
"products": {
"nationalExpress": false,
"national": false,
"regionalExp": false,
"regional": false,
"suburban": false,
"bus": false,
"ferry": false,
"subway": false,
"tram": true,
"taxi": false
}
},
{
"type": "stop",
"id": "738726",
"name": "Hegermühlenstr., Strausberg",
"location": {
"type": "location",
"id": "738726",
"latitude": 52.57423,
"longitude": 13.883165
},
"products": {
"nationalExpress": false,
"national": false,
"regionalExp": false,
"regional": false,
"suburban": false,
"bus": true,
"ferry": false,
"subway": false,
"tram": false,
"taxi": false
}
}
]
Doing a similar request for, (typical for me) Alexander platz in Berlin, I filter on ‘suburban’ which is a synonym for S-Bahn and get to:
curl ‘https://v5.db.transport.rest/journeys?from=8080680&to=8011155&to.longitude=13.411088&to.latitude=52.521526’ -s | jq
And get a plethora of results which include (the second response) an option with the tram to the the S-Bahn.
I’m assuming you’re trying to get around latency and pre-fetching stations or some such? I’m just exploring the apis and was farily impressed !
Yes, MultiModal is not designed around this type of APIs as Fahrplan may be. It keeps a local database of stops and lines and uses the API just to fetch real time station boards and for journey planning.
The beauty of this approach allows e.g. to display all the bus stops around you on a map when walking without firing out too many API calls.
Ah, ok. I’ll have a look at the python and see if I can be of help collecting stations. Fahrplan shamelessly ‘abuses’ the apis.
You can find the stations database here:
sqlite3 /usr/share/harbour-multimodal/route.db
sqlite> SELECT * FROM stop_points WHERE numbering_area = 2 AND lat BETWEEN 52.51 AND 52.59 AND lon BETWEEN 13.41 AND 13.49;
8010255|BHF|Berlin Ostbahnhof|52.5104881|13.4346807||||||10|6|3|2|1624696899|1624696899
8011155|BALE|Berlin Alexanderplatz|52.521481|13.410961||||||10|4|3|2|1624696899|1624696899
8089001|BALX|Berlin Alexanderplatz (S)|52.521642|13.411007||||||10|4|3|2|1624696899|1624696899
8089011|BGFB|Berlin Greifswalder Str|52.54002|13.439561||||||10|4|3|2|1624696899|1624696899
8089013|BFAL|Berlin Frankfurter Allee|52.515168|13.47441||||||10|4|3|2|1624696899|1624696899
I’ve found something what looks like the most current and complete data set for VBB regional transit, which should include Berlin:
https://www.vbb.de/fileadmin/user_upload/VBB/Dokumente/API-Datensaetze/gtfs-mastscharf/GTFS.zip
Sadly they also seem to be using a completely different stop-point ID scheme than the (transport.rest) VBB API expects.
https://v5.vbb.transport.rest/journeys?from=900000100003&to=900000100004
Edit:
The DHID looks something like that e.g. “de:11000:900170019” - which is not exactly the same but looks familiar enough to the type of IDs we see on the API.
e.g. taking the 900170019 part and inserting 3 zeroes behind the initial 9 to form 900000170019 seems to be doing the trick:
https://v5.vbb.transport.rest/journeys?from=900000100003&to=900000170019
I will have to find out if this remains consistent over the whole VBB network but this approach looks very promising.
As I found out calculating the stop ID from DHID reduces the location from e.g. the actual tram stop to a cluster of stops which means the API will return departures for all trams, buses, etc. in this cluster all mashed together which is generally not what we want.
I’ve added a work around to allow adding stops that aren’t available in the local data set.
The search dialog on the “Routing preferences” page (when Germany is selected as area) uses the transport.rest API to look up arbitrary stops and allows saving them to favourites.
Hey! I downloaded the update. Using routes I now find my way exactly as I do with Fahrplan. Yeah!
The additional data, stops between on the U-Bahn for instance, is probably more than needed but your walking directions are more precise. The walking icons, however, are hard to see in the initial list of Journeys.
All in all, top! It’s a real alternative for navigating around here.
That’s one of the features I actually use a lot when travelling in a city I’m not familiar with. It helps me to determine if I’m actually going the right way and also to know one stop in advance when I will have to go off the train etc.
Yes, I think I should maybe create a new icon (e.g. on a gray background) along with the train icon which does not really fit the look of all the other icons used in the app.
Yeah, I was thinking in my boring commuter way. Bad habit. I showed it to my GF who is a ninja commuter and she really liked it. She said switching views in the official app is a pita. And the layout is really well, done!
I was going to suggest making the walking guy a green. The Green Walking Guy is famous in Berlin https://www.ampelmann.de/
In any case, nice work!
Thank you.
One of the driving forces behind developing this app was not just that official apps don’t exist (which is not much of an issue with Android support) but also their looks and usability.
E.g. I see them often waste 1/3 of the screen real estate on buttons and truly useless information all which could be easily hidden in a pull down menu on SFOS.
I want my apps to be as little distracting as they can possibly be - which may sound a bit odd from someone who uses large rectangles of flashy colors in his app.
Having just updated to the latest version, I seem to have lost my Favourites. No worries because I’ll search for and add them again. I also can’t seem to locate the About screen in the current version (and my App Icon doesn’t show any national flags yet! ).
Thanks for the continued development of what is undoubtedly the best transport App for Sailfish in the UK.
Yeah, I don’t get persistence of faves either. Presumably sailjail thing.
Sorry, looks like migrating to a different table structure may have taken them out.
This was only meant to be displayed on openrepos.net to highlight the fact that the app now supports multiple countries. The app started as a purely UK thing so it may not be obvious to someone scrolling by in Storeman that this may have changed over time.
But I’ve created a different icon which is styled more after the example icons provided by Jolla.
Thank you!
If this issue persists it may be a Sailjail thing but if the entries just disappeared once after the last update it is more likely this happened due to a database migration that does not take existing table content into account.
Hmm. Just checked again. There is no history since I last checked a route or a location. You’re not using Settings from QML so I’d guess you’re doing db writes directly? Tidings does this and, I’m not sure if it makes a diff, but for the db I don’t use the .conf dir but .local/share/orgname/appname …
In the case of tidings I’m supplying a Database object from c → qml, so it’s probably completely unrelated.
EDIT: I tried running it without sailjail from the cli and the history doesn’t show either.
May be due to the fact that I haven’t implemented saving history yet
I have to figure out the best way to serialize all the data plus also have to add an option to to the settings page to disable saving history if someone is paranoid or something.
Saving individual stops/stations should work, though.