OpenLDBWS GetDepBoardWithDetails using offset

135 views
Skip to first unread message

Mark Jenkins

unread,
Oct 21, 2022, 4:25:53 AM10/21/22
to A gathering place for the Open Rail Data community
Hi All,

Technical question regarding the behaviour of the offset parameter available with GetDepBoardWithDetails SOAP request.  

I have some logic that observes the maximum time window (diff between now and last scheduled departure) of services in the first board that's returned to pull a subsequent board using that time offset.  When the time window is 5 minutes or more, this works fine and I receive up to 20 services from the two calls.  However when it reduces to 2 minutes or less the 2nd GetDepBoardWithDetails call returns return the same board apparently ignoring the offset.

Question - Is this expected behaviour, does the GetDepBoardWithDetails end point have a minimum practical value for the offset?

The documentation suggest that it doesn't have any kind of restriction:

TimeOffset (integer, between -120 and 120 exclusive): An offset in minutes against the current time to provide the station board for. Defaults to 0. Optional.

I use parameters crs=LBG, numRows=10, parmOffset, parmWindow=120 and of course requestType=GetDepBoardWithDetailsRequest.  I'm not using the filterCrs or filterType parameters.  

In the following example the logic is chaining 3 such calls but getting identical boards each time.

[1] maxDepTime 1
[1] first service CST plat 3 departs 09:03
[1] Last service CST plat 2 departs 09:17
[1] Count: 10
[2] maxDepTime 1
[2] First service CST plat 3 departs 09:03
[2] Last service CHX plat 8 departs 09:17
[2] Count: 10
[3] maxDepTime 1
[3] First service CST plat 3 departs 09:03
[3] Last service CHX plat 8 departs 09:17
[3] Count: 10

Results are in attached image.  The above calls were made at 9.16 with the offset = 1, what I expect to see are the departures scheduled from 9:17 onwards however I get the same 3 boards as indicated above.  The issue may be well related to the delayed services showing from 9:03 onwards.

Simulator Screen Shot - iPhone 14 Pro - 2022-10-21 at 09.17.27.png

Any help or suggestions appreciated

Many thanks
Mark

RailAleFan

unread,
Oct 21, 2022, 7:19:17 AM10/21/22
to A gathering place for the Open Rail Data community
Hi Mark,

There is something like a 2 minute window where services that have not yet reported actual timing are still included in the result set so I think that is what you are seeing here with regards to the 09:15 and 09:16 on time departures.

The delayed services from 09:03 onwards will remain in results until now+offset goes beyond their expected departure time (and I _think_ for ~2 minutes after that), so for a query made at 09:16, assuming (now+offset+2) it would require an offset of 11 minutes before the 09:03 to CST is not included in the response...

Cheers

Mark Jenkins

unread,
Oct 21, 2022, 7:50:10 AM10/21/22
to A gathering place for the Open Rail Data community
Hi and thanks for getting back,

That makes sense.  I had tried driving the window based on the max estimated time of departure for the prior board which in effect does what you're suggesting.  The problem there is it creates gaps in the as the next board is offset a bit too far.

I saw there is a "time" parameter for OpenLDBSVWS and am going to give that a try, see if I can direct the API to retrieve the board at the specific time of the last departure + 1 min.  It might give better behaviour over the offset approach assuming the parameter works the way i expect.    Need to switch to the Staff API first of course, have requested a token.

Of course it may just work the same way as offset in which case I'm stuffed...

Cheers
Mark

Reply all
Reply to author
Forward
0 new messages