Feature Request: Support Regional Trains

[benjaminweb]

DB Zugradar provides

• ICE
• IC/EC
• RE/RB trains

Currently, as I got it, db-zugradar-client provides data for long-distance trains (ICE & IC/EC) only.

If there is an option to retrieve data for regional trains with db-zugradar-client, would you be so kind to deem its own place in the documentation, please?

If there is none, might you consider including regional trains?

[derhuerst]

The request logic doesn't contain any filtering/option for specific train types. If you provide me with recorded network requests or more info on how to fetch regional trains, I'm happy to support them.

[benjaminweb]

;TLDR: Iterate performFixedLocating from 1 through 23 to include regional trains.

@makujaho (kudos for the link to the MRMCD15 talk ) iterates over 1 through 23 (including) as value for performFixedLocating: https://github.com/makujaho/trainspotter/blob/master/trainspotter.py#L12

performFixedLocating: 1 // seems to return only the long-distance network performFixedLocating: 2 // through (including) performFixedLocating: 23 // seems to yield the tiles for both regional and long distance trains

How to end up with long distance and regional trains only? => {{2-23}} - {{1}}

[derhuerst]

1 and 23 seem to be DB bitmasks representing different modes of transport:

require('db-hafas/lib/modes').parseBitmask(23)
{ nationalExp: true,
  national: true,
  regionalExp: true,
  regional: false,
  suburban: true,
  bus: false,
  ferry: false,
  subway: false,
  tram: false,
  taxi: false }
require('db-hafas/lib/modes').parseBitmask(1)

{ nationalExp: true,
  national: false,
  regionalExp: false,
  regional: false,
  suburban: false,
  bus: false,
  ferry: false,
  subway: false,
  tram: false,
  taxi: false }

[derhuerst]

15 seems to be the correct bitmask, but I haven't checked with db-zugradar-client yet.

[benjaminweb]

;TLDR: performFixedLocating seems to be geographical selector, not bitmask for mode of transport

Let's check, whether this is plausible:

• performFixedLocating: 8 would yield only regional trains like RE and RB, however does include ICEs
• performFixedLocating: 16 would yield only S-Bahn lines, however does include regional trains like RE

If they were bitmasks, values of 8 and 16 addressing a single group exclusively would therefore not include elements of other groups (but only parts of them). Additionally,

Observation: Network requests on the map around Cologne consistently load performFixedLocating values of 9 and 12 while around Frankfurt only 9, for Nuremberg 13, for Passau 14, Stuttgart 12 and 13, Munich 13 and 14, Berlin 8 and 11, Hamburg 6 and 7, Hannover 6, 7, 9 and 10, Magdeburg 10 and 11, Duisburg 9.

To me it seems (please prove me wrong!) performFixedLocating references a geographic tile. The name itself suggests a geographical selector. performFixedLocating: 1 seems to me to be a special selector for national trains. If performFixedLocating actually turns out to be a geographic selector, you may have concluded from your background with the db-hafas for the other values of performFixedLocating to be a bitmask.

---

Prototype (not the JS framework):

curl -O https://gist.githubusercontent.com/benjaminweb/2ee9fe3d14d240a143f7623098d545b9/raw/aca1c75329c8b7595ee14b8e3a6b61a02c2db698/db_trains_list.py
pip3 install --upgrade requests
ipython3

Therein:

from db_trains_list import get_trains_detailed
both = get_trains_detailed(regional=True, national=True)
len(both)

[derhuerst]

;TLDR: performFixedLocating seems to be geographical selector, not bitmask for mode of transport

Sounds reasonable as well. 😛

I'm not happy with sending 24 requests. There must be a better way. If not, let's put this into another module, e.g. db-zugradar-client/regional.

[benjaminweb]

Me neither.

Retrieved trains per second drops by ~25 percent for 24 requests for test loop performed at 2017-06-13 11:43 CEST:

requests	trains	time	trains/s
1	275	70 ms	3929
24	4545	1430 ms	3178
24 *	5511	774 ms	7120

* with threading, 2017-06-13 17:46 CEST

~16 times the trains at 11 times the time consumed. Trains retrieved per second is up by ~80 percent.

[derhuerst]

Retrieved trains per second drops by ~25 percent for 24 requests for test loop performed at 2017-06-13 11:43 CEST:

Is that with your Python script? afaict it doesn't send the requests in parallel, which is why it drops.

[benjaminweb]

Yes. I updated the python script employing threading, subsequently the result table.

[derhuerst]

Retrieved trains per second drops by ~25 percent for 24 requests for test loop performed at 2017-06-13 11:43 CEST:

Did you test with more than one run?

[benjaminweb]

Yes. However, I have no clue about caching. — What a brilliant idea to port the python script to JS. But not today.

The slowest run took 5.50 times longer than the fastest. This could mean that an intermediate result is being cached.
1 loop, best of 3: 774 ms per loop

In [167]: %timeit -r 1 both = get_trains_detailed(regional=True)
1 loop, best of 1: 1.67 s per loop

In [168]: %timeit -r 2 both = get_trains_detailed(regional=True)
1 loop, best of 2: 1.06 s per loop

In [169]: %timeit -r 3 both = get_trains_detailed(regional=True)
1 loop, best of 3: 643 ms per loop

In [170]: %timeit -r 4 both = get_trains_detailed(regional=True)
1 loop, best of 4: 716 ms per loop

In [171]: %timeit -r 5 both = get_trains_detailed(regional=True)
1 loop, best of 5: 798 ms per loop

In [172]: %timeit -r 10 both = get_trains_detailed(regional=True)
1 loop, best of 10: 661 ms per loop

In [173]: len(both)
Out[173]: 5511

%timeit\'s reference:

[…]
-n<N>: execute the given statement <N> times in a loop. If this value
is not given, a fitting value is chosen.
-r<R>: repeat the loop iteration <R> times and take the best result.
Default: 3

In [178]: %timeit -n 3 -r 10 both = get_trains_detailed(regional=True)
3 loops, best of 10: 856 ms per loop

[derhuerst]

The queueing mechanism could work like in vbb-departures-in-direction.

[derhuerst]

The Zugradar got turned off.