DARWIN Concerns - Missing Services

[Morgan]

Been playing with the DARWIN feed lately and seeing a worrying discrepancy on data from the feed to data on Network Rail

Here is a screen shot of a custom Darwin feed (right) and NR data (left)

This is not a one off, whilst coding last night I saw several missing feed and I also think they were also WALES based.

This time table is based on SWINDON departures.

Am i missing something about Darwin feeds, some small print or is this due to this experimental nature (the open feeds being new, I am aware Darwin itself is not a new system)

[Morgan]

Actually.. ignore this

Turns out I had some asychronous calls going on that were too fast for the processing hence were being skipped so I just need to redo my data gathering functions

[Rail Ale Fan]

Nice looking output!

i think it would be good if Darwin supported an expanded station board request that included service detail for each entry as it would save the multiple requests required to create displays as per your screenshot, and my Destinations A-Z boards ( http://www.railalefan.co.uk/rail/destinations/Reading/ )

Anything innovative to come out of public access to Darwin is almost certainly going to require some level of service detail so it would save a LOT of hits on the server, and with bandwidth rapidly becoming "too cheap to meter" that's not really an issue either...

[Peter Hicks]

On 12 Mar 2015, at 17:12, Rail Ale Fan <raila...@gmail.com> wrote:

> i think it would be good if Darwin supported an expanded station board request that included service detail for each entry as it would save the multiple requests required to create displays as per your screenshot, and my Destinations A-Z boards ( http://www.railalefan.co.uk/rail/destinations/Reading/ )
>

> Anything innovative to come out of public access to Darwin is almost certainly going to require some level of service detail so it would save a LOT of hits on the server, and with bandwidth rapidly becoming "too cheap to meter" that's not really an issue either…

This falls in to the lower end of what you’d likely use the Push Port for...


Peter

[Mike Flynn]

> would save the multiple requests required to create displays as per your screenshot, and my Destinations A-Z boards ( http://www.railalefan.co.uk/rail/destinations/Reading/ ) 

RailAleFan, I see your AZ Board is structured as per the Train Times boards on stations concourses.  Something I've thought of doing also.  Have you plans to expand further, eg., to show, say, the next few trains for each destination?  

> just need to redo my data gathering functions

Morgan, I don't mean to hijack the thread!  Yes, it is a better display this way.  And yes also, as it currently stands with Darwin, does also have necessitate the multiple requests issue.

[Morgan]

I have created the basic timetables like the Reading example with no problems, but I wanted to take it to the next level =)

I do think the DARWIN feed could be structured a little better.. having to query the station for the code and then querying the details with the code obtained seems a little fussy, but hey, we work with the tools given!

[Mike Flynn]

Morgan: 

What I'd like to implement is something similar to your live list but also/or using the NR raw schedule timetable data.  Just like these station Train Times boards with individual destinations listed alphabetically then showing the times of all trains for the week. 

I'd be interested to know how you generated your list of destinations for any particular station.  I can see how this could be possible using NR's raw timetable data to create lookup tables.  I also imagine it's possible by making multiple requests to DARWIN.  From your above post mentioning the multiple requests I wonder have you done it this way?  

[Rail Ale Fan]

HI Mike,

I wondered if your question might have been directed at me WRT to the A-Z boards, in which case, in my case it's the multiple requests to Darwin way.

Specifically, a GetDepartureBoard request for the next 10 services, and then a GetServiceDetails request for each.service.  Results then sorted per unique destination by soonest `et` (or `st` if et = "On time")...

Cheers

[Mike Flynn]

RailAleFan, yes the question should have been directed at you.  

So, quite a few requests per page.   Is there an argument then for the provider to offer also a combined GetDepartureBoard/GetServiceDetails?  I'd say there's a number of strands to this question.  

From the client point of view, on the face of it, there's no question it would be better to have the option.  For example, if you wanted a display like yours or Morgan's.  Page load, bandwidth, processing, all would be reduced.  The only downside, and it could be argued, it could lead to lazy design choices.  Does the audience need all this extra information considering 99% will be looking just for their single train?  

However, from the providers point of view bandwidth and processing power would undoubtedly increase.  And as we know NRE aren't in this for the money.  Their charging policy is designed to cover cost rather than make a profit.  

I would argue that overall, having the option would be better.  Morgan's display is certainly more aesthetic and your's allows the viewer to quickly find his destination without the need for further typing and clicking.  And scaled up you might'nt then be faced with the choice of having to pay more.