Why would platform data be missing?

[Tim Nightingale]

I have a project where I am consuming the Darwin data feed, but for the last couple of days Birmingham New Street (BHM) hasn't been providing platform info. Other stations I have been testing with are fine. 

Is that feature slowly being turned off?

Many thanks, 

Tim

[Peter Hicks]

Hi Tim

On Monday, 30 March 2026 at 16:51, Tim Nightingale <1timnig...@gmail.com> wrote:

I have a project where I am consuming the Darwin data feed, but for the last couple of days Birmingham New Street (BHM) hasn't been providing platform info. Other stations I have been testing with are fine.

Is that feature slowly being turned off?

No, but it looks like the CIS at New Street may not be connected to Darwin.  It could be a fault, it could be by omission, but either way, it's not the norm.

See previous messages on the group regarding platform data via Darwin for details.

Peter

[Tim Nightingale]

Peter, 

Thanks for the prompt reply. 

I have ready through posts, and can see that during adverse conditions (weather and otherwise) they might disconnect it. But then I suppose they might then forget to re-connect it. (Like the smart motorway signs being stuck on 50 for what seems no reason). 

In one post, RDG said:

Rail Delivery Group

...

unread,

1 Feb 2019, 10:28:28

...

Centrally we have a monitoring tool which we can look at to see which CIS is connected to Darwin or not, although I'm not aware of a way to make that information available to the wider community as yet. I'll note it however as a potential option for the future.

...

RDG

I wonder if they still have monitoring tool active, or an updated way to keep informed. 

I notice it isn't just me affected, some TOC Apps and even NR Live Departues board have the same issue. 


As mentioned by other posts, it puts a little damper at times on what is an excellent service. 

Tim

[Tim Nightingale]

Update: 

I happened to be passing through BHM this afternoon, so thought I might enquire at the Network Rail Customer Service desks. 

The gentlemen seemed to understand what I was attempting to explain, and informed me they were having an issue with it recently, no more details or an estimate of when it might be resolved. 

I am not sure if I was being fobbed off or not, but didn't want to appear pushy or a know-it-all, so thanked him and wished him a good day. 

The bit that I find missing is that the Darwin feeds are used by many solutions, including National Rail themselves. Do they have a 'status' page where they can highlight known issues with the feeds?

It is such a great resource they make available, and I understand there is a cost to maintaining a 'free' service, but data quality and availability must account for something. I don't want these things to deter others from using it. 

(Hopefully I am making sense)

Tim

[Peter Hicks]

Hi Tim

On Monday, 13 April 2026 at 19:17, Tim Nightingale <1timnig...@gmail.com> wrote:

I happened to be passing through BHM this afternoon, so thought I might enquire at the Network Rail Customer Service desks.

The gentlemen seemed to understand what I was attempting to explain, and informed me they were having an issue with it recently, no more details or an estimate of when it might be resolved.

I am not sure if I was being fobbed off or not, but didn't want to appear pushy or a know-it-all, so thanked him and wished him a good day.

Often, if the station CIS is disconnected from Darwin, it will be outside the control of station staff.  The CIS continues to work without a connection to Darwin, and functionality at the station is minimally affected whilst IT people go about fixing the issue.  Having worked in network engineering for a number of years before rail, it can be a frustrating experience with lots of finger-pointing, especially if multiple teams are involved.

I will say that emails have been sent out to station managers (and I was bcc'd in) reinforcing the importance of keeping their CIS connected to Darwin after I brought it up in a meeting a few months ago.  David Wheatley has also built https://wheresmyplatform.com which covers London, but I suppose could be added to cover other major stations, which should shine some light on the problem.

The bit that I find missing is that the Darwin feeds are used by many solutions, including National Rail themselves. Do they have a 'status' page where they can highlight known issues with the feeds?

Nothing like this exists that is public - but you make a very good point.  An API that drives a web page which shows the station of Darwin CIS clients would be useful to an extent - for example, you could see right now that the Birmingham CIS has been disconnected since 12:28 on 28th March.

Peter

[Peter Hicks]

On Monday, 13 April 2026 at 19:31, 'Peter Hicks' via A gathering place for the Open Rail Data community <openrail...@googlegroups.com> wrote:

Often, if the station CIS is disconnected from Darwin, it will be outside the control of station staff.  The CIS continues to work without a connection to Darwin, and functionality at the station is minimally affected whilst IT people go about fixing the issue.  Having worked in network engineering for a number of years before rail, it can be a frustrating experience with lots of finger-pointing, especially if multiple teams are involved.

I've spoken to one of the people involved in fixing the problem, and it turns out to be quite complex involving multiple teams and different suppliers.  I'm afraid I can't go in to details, but the right people are on the case and actively managing it.

Peter

[Tim Nightingale]

Many thanks for the replies... It is nice to know that someone reads my babbling :-)

I have had a look at David Wheatley's solution, and think I will test a version that looks at more stations... but of course being very careful on limitations. 

Regarding the feed status page, this would be a nice inclusion to have as a seperate feed, so that downstream it can be highlighted as a known issue. Having spent many years in data and analytics, it always seems to be the front end that gets the blame, where in instances like this, we could highlight a known issue with data feeds and it is being worked on. 

Tim

[David Wheatley]

 I have had a look at David Wheatley's solution, and think I will test a version that looks at more stations... but of course being very careful on limitations.

You're also more than welcome to open a pull request: https://github.com/davwheat/wheresmyplatform.com

:P 

--
You received this message because you are subscribed to the Google Groups "A gathering place for the Open Rail Data community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openraildata-t...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/openraildata-talk/ffd935bd-a14f-4ff3-88c3-ab4744502b26n%40googlegroups.com.

[Tim Nightingale]

2,599 stations mapped and rated. 

Oddly BHM is showing as 100% but my Darwin feed is still down.. so next to work out the differences. 

Once I finalise this I will share it.

Tim

[Tim Nightingale]

I found the discrepancy, the platforms are publicly hidden.. so I have updated my map to hopefully match the public Darwin feed. 

Tim

[Tim Nightingale]

Hi, 

I now have this version available to view, 
https://nexttrains.co.uk/wheresmyplatform.html

The colour coding takes into account the platforms hidden from the public. 

There is a background process that is collecting the data every 10 mins. This prevents an flurry of requests everytime someone view it. 

If there is something amiss, please let me know. 

Regards,

Tim

[Peter Hicks]

Hi Tim

This looks really good, well done!  It's highlighted a potential issue with 'new' stations where they appear to have their platform number suppressed.  Check out Apperley Bridge, Kirkstall Forge and Low Moor for example.

The passenger impact of this is likely to be minimal - Apperley Bridge, for example, does not have bidirectional signalling and Shipley-bound trains will always leave from the same platform.

Peter

To view this discussion, visit https://groups.google.com/d/msgid/openraildata-talk/a6b010fb-d920-4504-a2ec-30d4e152730bn%40googlegroups.com.

[Tim Nightingale]

Peter, 

I simply adapted the solution you have built, thanks for letting me do so. 

One thing it is useful for is where people have/are developing solutions to show departures, they can find out that they are reporting the data presented to them, and not a problem with their code. 

Tim

[Peter Hicks]

On Thursday, 16 April 2026 at 13:48, Tim Nightingale <1timnig...@gmail.com> wrote:

I simply adapted the solution you have built, thanks for letting me do so.

I can't take any of the credit, it's all David Wheatley's code.

Peter

[Tim Nightingale]

Sorry for the mistake... I have credited David on my page too. 

Tim

[Tim Nightingale]

Many thanks for allowing me to use your solution. 

Tim

On Tuesday, 14 April 2026 at 15:59:59 UTC+1 David Wheatley wrote:

[Tom Cairns]

I would hope that you’re planning on open sourcing your iteration on David’s work given his was open source in the first place so that we are able to more broadly benefit.

 

Tom

 

To view this discussion, visit https://groups.google.com/d/msgid/openraildata-talk/95b0368c-3e18-4591-83a4-3dc219bf4e6cn%40googlegroups.com.

[Tim Nightingale]

Of course... Just needed a little tidying up. 

The repository is available here:
https://github.com/1timnightingale/wheresmyplatform.com.git

Regards,

Tim

[Adam Williams]

The figures seem to disagree wildly with reality - I'm not aware of any issues with Euston. Is it checking whether the platforms are advertised e.g. 15 minutes (or some % of the turnaround time) before they departed in Darwin? Or is it just considering all services, including future ones? It's expected, given the silly games played at Euston, that the platforms will be suppressed for at least some of the time - which is of course why so many passengers will use RTT or other services to avoid the stampede - but this shouldn't be flagged as a systems issue.

[Seb Dazeley]

I wonder if Tim's site uses the final state of the platform to decide if it's publically provided or not? Euston will re-supress its platforms 2 minutes before departure, so the site needs to check if the platform was advertised at some point instead of if it's supressed in the final state of a service.

I am currently developing my "power user" Darwin site which is semi-public (the link to it in the top navigation bar doesn't work unless you're already in the Darwin section) and a work in progress (for example I still haven't got around to replacing TIPLOCs with proper station names and search is a bit tempremental)

You can see this in action by clicking "Load History" and looking at update #14 then #15 with this service for example https://vaildata.uk/darwin?rid=202604188702432

To view this discussion, visit https://groups.google.com/d/msgid/openraildata-talk/8fc89066-36ce-4506-988e-dcd8b1851504n%40googlegroups.com.

[Adam Williams]

Oh wow, that site is very useful; I wasn't actually aware they re-suppress platforms 🤦‍♂️. So a passenger who's just boarded the train and wants to double check they're on the right service will see the platform disappear from in front of their eyes when they look at an app. Amazing.

Seems to happen at Kings Cross too (3 whole minutes before departure for e.g. C41041 - seems pretty excessive to me). And yet I don't recall this sort of nonsense being done at Birmingham (back when Darwin worked!). To my knowledge this is definitely not done at Edinburgh, or Manchester Piccadilly or other cat A stations.

[Gaelan Steele]

On Apr 18, 2026, at 12:41, Seb Dazeley <sebda...@gmail.com> wrote:

You can see this in action by clicking "Load History" and looking at update #14 then #15 with this service for example https://vaildata.uk/darwin?rid=202604188702432

Oh! You’re the Vaildata person!

Many thanks for your routing map viewer - it’s a fantastic tool. 

Best,

Gaelan

[Tim Nightingale]

The code looks at the number of services with platforms in a time period (120 mins historical) and determine how many have the platform hidden (from public). 

In the data collection I am only collecting totals, so the platform isn't revealed unknowingly. It isn't for me to decide who should see it, especially if there is a flag indicating suppression. 

Would it be possible for a service to have the platform revealed locally, but then not released to Darwin? 

I also assume the is correct at query time, so no history can be determined as to when the platform was made public (before or after departure time, if at all) and likewise if it was hidden again. 

Tim

[Tim Nightingale]

I see what you mean... 

I suppose at the moment there isn't a flag that says this was made public, unless every change is captured, such as your solution. 

I was also interested that the source for some of your info was CIS... and the issue many public apps/solutions have is they are using Darwin. 

Tim

On Saturday, 18 April 2026 at 12:41:29 UTC+1 Seb Dazeley wrote:

[Seb Dazeley]

A source of CIS has still come through the Darwin feed. Everything on that part of my website is from just the push port and daily timetable file. The push port gives a source for each message which is usually CIS, TRUST, TD or Darwin. Darwin is normally automatic forecast (TS/Train Status) updates, TRUST and TD actual arrival and departure times, and CIS is manual adjustments and alterations (and automated actions not from Darwin itself). 

The above might not be 100% accurate but it's correct to the best of my knowledge. 

Unfortunately, if you don't process messages live from the push port I don't think there is a way on knowing if a platform was previously advertised. It's not necessarily a bad thing to have some services pulled, for example if disruption has just started and there are last minute cancellations, set swaps, or just uncertainty but it seems a bit too widespread. I agree with what Adam said, it's not good if someone tries to check with their phone they've got the right platform and it's dissappeared.

Would it be possible for a service to have the platform revealed locally, but then not released to Darwin?  

To give a bit of a non-answer, I don't see why this feature would be needed for individual service level, but I wouldn't be surprised if it's something stations can do. Also, services might not be advertised digitally - there's always manual PAs or if there is a queuing system (Marylebone on WCML closure days and St Pancras on ECML/WCML closure days come to mind) simply staff verbally telling people where to go. If this is/becomes regular practice it would be bad for many reasons, not just accessibility. 

There are two different platform suppression fields. I will try to look into the difference between then soon, I have a vague memory there's something in the spec but I'm not sure. Unless some special handling has been built in, there must be something going on as railchecker.app shows past services from Euston don't have suppressed platforms while ones from Marylebone do. My current parsing logic thinks both stations have suppressed platforms after departure. 

To view this discussion, visit https://groups.google.com/d/msgid/openraildata-talk/b8fac675-8932-478e-b865-f8ea5506929dn%40googlegroups.com.

[Tim Nightingale]

Is am now starting to see this as separate things... 

1) Measuring accuracy of stations platform data being made available to the public Darwin feed. This should count if a service platform was available at somepoint before departure.
2) For public facing apps and websites using the Darwin feed, They should only show what is currently public facing - and so honour the flags in the data (this is probably covered in the license). 
3) How do we accurately show there is an issue with the data being fed (or not) into Darwin, like there seems to be at BHM?

(Separate question: was there an big upgrade/outage this morning?)

Tim

[Peter Hicks]

Hi Tim

On Sunday, 19 April 2026 at 08:52, Tim Nightingale <1timnig...@gmail.com> wrote:

1) Measuring accuracy of stations platform data being made available to the public Darwin feed. This should count if a service platform was available at somepoint before departure.

How do you measure accuracy in this case?  If you're just looking for any​ platform being displayed against a service prior to its departure, validating that the platform number in Darwin is correct seems superfluous as the same data should be displayed on the station boards as it is on Darwin.

3) How do we accurately show there is an issue with the data being fed (or not) into Darwin, like there seems to be at BHM?

Look for any​ platform showing for any​ train in the next hour - I think that's what David's original code did.  The failure mode of a CIS not connected to Darwin is that no platform data shows for any service, so work on that basis.  If there are no trains in the next hour, show "unknown".

(Separate question: was there an big upgrade/outage this morning?)

You're gonna have to be more specific here.  Upgrade/outage to what?  What did you see?  What times?

Peter

[Tim Nightingale]

Hi,

You. raise an interesting point with the response to the 3rd question;
David's code does indeed count services that have platforms identified and shows that as a percentage of services returned in the time frame. Mine was doing the same, and would show BHM as 100%. All BHM services in the LDBSVWS have platforms, but they are all flagged to have the platforms hidden. So solutions using the non-staff version are unable to display the platform. 

I can understand where a station might unhide it and re-hide it close to departure, but BHM doesn't seem to unhide any of them at the moment. 

For this reason I was trying to show what percentage of platforms are not available to be displayed. This could then match the users experience with solutions (including National Rails own live departure boards) using the LDBWS API. 

Many of us will be aware that the front end gets blamed first, but if the data isn't available then there is little the [solution] development team can do. 

But this does raise the issue of how to fairly measure each station in a uniform way, and what are we measuring, did each service have a platform assigned in the data or are solutions using the data able to display it?

Regards,

Tim

[Tim Nightingale]

A quick note: 

I think part of the issue at BHM is that incorrect platforms are making it into the data feed. There was an announcement there this morning and I could see if reflected in the data. 
In those cases, a Platform was listed, and the platform hidden, but the data is incorrect. So could it count as having platform information?

Tim

[Tom Cairns]

I think you would need to monitor train services during the course of the day (probably push port for this, tbh) and look to see if the platform is unsuppressed at any time. You wouldn’t be able to take a snapshot approach. 

Tom

--
You received this message because you are subscribed to the Google Groups "A gathering place for the Open Rail Data community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openraildata-t...@googlegroups.com.

To view this discussion, visit https://groups.google.com/d/msgid/openraildata-talk/eb631b3d-f345-4796-83d7-b5d4602adb7dn%40googlegroups.com.

[Oscar Harris]

It looks like this is still broken. I fear this will turn into yet another months long saga like when Kings Cross got disconnected.

There may well be multiple suppliers involved, and I'm well experiences in how this can complicate incident response. However, when we're talking about major outages affecting one of the busiest stations in the country we should still be talking about fix times in hours and not days or weeks. As far as I'm aware, there hasn't even been any updates on progress sent to parties within the industry who are affected and have reported it.

It shows a lack of care from (at least some of) the organisations involved, as well as some concerns about the contracts in place - surely there are SLAs in place that someone is breaching dramatically, and they should be rather heavily incentivised to fix the issue sooner rather than later. This is rather essential data for the industry as well as open data consumers, and the suppliers and those who have contracted them need to act like it.

I appreciate no one in this list is directly involved, and this isn't a problem specific to open data (though it affects it as well as affecting everyone within the industry), but I think we need to call out when major incidents are badly handled.

Oscar

--
You received this message because you are subscribed to the Google Groups "A gathering place for the Open Rail Data community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openraildata-t...@googlegroups.com.

To view this discussion, visit https://groups.google.com/d/msgid/openraildata-talk/leBqNIuajdiUE9Jh9WhuqE3DC5CtX6RW7PSgNlCfXS138Ud2E5UZ0QFPj9kvVouwVhpDwzq9gHK-9noD64TdSrHvrm5lxoOurp36ElzEDqU%3D%40poggs.co.uk.

[Peter Hicks]

Hi Oscar

On Thursday, 23 April 2026 at 12:36, Oscar Harris <os...@oscar-h.com> wrote:

I appreciate no one in this list is directly involved, and this isn't a problem specific to open data (though it affects it as well as affecting everyone within the industry), but I think we need to call out when major incidents are badly handled.

Not defending anyone's position here, but I'm not sure this is actually a major incident.  It's a degradation of information available externally from a system, and whilst inconvenient, its impact is limited.  You can still see platform numbers on the CIS at the station.  If somebody isn't able to read the CIS, then there are station staff available to help, which is a mitigation rather than a solution.  And if somebody is unable to speak to station staff for whatever reason... that's a particularly small number of people impacted which still doesn't make it a major incident.

I can't share details of exactly what the problem is, or who's involved or why it's taking so long - but there are a number of people reading this thread who are actively trying to sort this issue out, and who sit in the right place to put strategic fixes in to ensure this is resolved quickly in future.

You might be best to submit an FOI request to Network Rail to find out what the issue was, and why it took so long, once it's been fixed.

Peter

[Tom Cairns]

It is a sad indictment on the state of systems and their interconnectivity within the industry that we are in a position where we are having a discussion about fairly important data to do with where a train is going to be is missing from the “one version of the truth”. I am aware of examples where people have missed their train because platform numbers were not present in an app following the appropriate display rules.

 

Tom

 

From: 'Peter Hicks' via A gathering place for the Open Rail Data community <openrail...@googlegroups.com>
Sent: 23 April 2026 13:08
To: openrail...@googlegroups.com
Subject: Re: [openraildata-talk] Why would platform data be missing?

 

Hi Oscar

--

You received this message because you are subscribed to the Google Groups "A gathering place for the Open Rail Data community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openraildata-t...@googlegroups.com.

To view this discussion, visit https://groups.google.com/d/msgid/openraildata-talk/c1DaHF15d1bntpXJb61Leulv9eK7M5C3JYdLboO8lx7ayK-64WeyWJL9PlSW28IPNFb0-fLEIHPTDiyVIpuOeXXh9-0DtAtBgi1hU0Wm5Fk%3D%40poggs.co.uk.

[Mike Wooldridge]

Apologies Peter but I think the idea of it not being a 'major incident' is flawed. If it had failed for a short period (hours/days) I'd agree with your assessment, but if my ticket retailing app of choice always shows me confirmed platform data when available (either as a push notification or within a live times section within the app), and it suddenly stops working - not for days or weeks but for an extended period now lasting in the order of months - at one of the UK's busiest rail interchanges, that is far from ideal, particularly when platform-level screens are so sporadically located due to the length of the platforms. 

Incidentally I almost missed a +10 connection there a couple of weeks ago because I had luggage and there were queues for the lifts both directions. If I didn't have advance sight of the platform (via RTT, which doesn't take its platform data from Darwin) I would have missed that connection and probably ended up in a long back and forth with CrossCountry's customer service team about why I should get delay compensation. I'd also hazard a guess that it's had an impact on workflows for certain station staff, for example those facilitating Passenger Assist. 

On their own, neither of those examples are showstopping, but when these workflow deficiencies drag on for as long as they have, and again considering the nature of a station like BHM, 'major' certainly seems to be an appropriate description for the severity of the problem.

Finally, I'm not trying to suggest there is a quick fix here.... ultimately the core of the problem here is that we have multiple different customer information system 'points of truth' for different displays within the UK rail industry. It's near-universally accepted that Darwin is the point of truth for customer-facing information regarding confirmed platforms, *except* that displayed within stations and other railway infrastructure and, being within the industry, I understand the history (broadly) as to why that is and why - in the real world - that exception will continue to exist in the short to medium term. But it is reasonable for the public to question why, in 2026, platform data availability differs electronically vs station displays (and that, if such a system was designed now, the same source of truth would power these too - there is a reason a number of European countries have their digital displays for stations as essentially internal web UIs querying exactly the same data sources as used on their external customer-facing websites and apps).

[Peter Hicks]

Hi Mike

On Thursday, 23 April 2026 at 14:01, Mike Wooldridge <m...@mikewooldridge.co.uk> wrote:

Apologies Peter but I think the idea of it not being a 'major incident' is flawed. If it had failed for a short period (hours/days) I'd agree with your assessment, but if my ticket retailing app of choice always shows me confirmed platform data when available (either as a push notification or within a live times section within the app), and it suddenly stops working - not for days or weeks but for an extended period now lasting in the order of months - at one of the UK's busiest rail interchanges, that is far from ideal, particularly when platform-level screens are so sporadically located due to the length of the platforms.

Going by the ITIL 4 definition of an incident, it's "an unplanned interruption or reduction in the quality of a service", whereas a major incident has "significant business impact, requiring immediate coordinated resolution".  Incidents are managed within an agreed SLA (although can go on longer if it's a difficult-to-fix problem), major incidents warrant immediate escalation.  The lack of platform data whilst the rest of the system is working makes it an incident, not a major incident. Inconvenient, yes - major?  No.

So that I don't sound like I'm trying to get the industry 'off the hook' here, it wouldn't have taken much effort to put a station message on for BHM reporting that confirmed platform data is currently unavailable.  Better still would be for the Push Port and associated APIs to have a flag showing that confirmed platforms were unavailable at the station so downstream systems could take appropriate action - but that's not an option that's available at the moment.

Looking at your scenario from a different angle - the design for the platform suppression and CIS platform suppression flags in Darwin was, I believe, so that systems didn't show any platform until it was confirmed.  That has slowly dissolved in to systems showing 'estimated' platforms (or in the case of Avanti services at Euston, a push notification to their app prior to the platform going up on the CIS) to try and get ahead of everything else.  The result is that we have a fairly brittle situation where the estimated/planned data is right most of the time, but you don't know when it's not right.

Finally, I'm not trying to suggest there is a quick fix here.... ultimately the core of the problem here is that we have multiple different customer information system 'points of truth' for different displays within the UK rail industry. It's near-universally accepted that Darwin is the point of truth for customer-facing information regarding confirmed platforms, *except* that displayed within stations and other railway infrastructure and, being within the industry, I understand the history (broadly) as to why that is and why - in the real world - that exception will continue to exist in the short to medium term. But it is reasonable for the public to question why, in 2026, platform data availability differs electronically vs station displays (and that, if such a system was designed now, the same source of truth would power these too - there is a reason a number of European countries have their digital displays for stations as essentially internal web UIs querying exactly the same data sources as used on their external customer-facing websites and apps).

We're only talking about the New Street CIS being disconnected from the Darwin CIS interface and thus unable to send confirm platform numbers up.  It's not as if station CIS always shows one thing and Darwin shows something completely different - in this case, Darwin shows nothing because it knows it doesn't know.

Peter

[Tim Nightingale]

Just to add a little bit here. 

For those who use un-confirmed platforms, as they are still supressed, that is there risk and should make their users aware to confirm with local departure information. 

But the main point being discussed in the last couple of posts looks at the issue from different places, but come down to one thing: Is the open data feed the single source of truth we are led to believe and how are consumers made aware of known issues?

I believe the is a platforms are hidden flag at station level which could indicate that the service platforms are not to be used (I am using that to fully surpress them). This could be when there is a local incident etc. 

At BHM they are aware of the issue and are making announcements informing the public platforms may be incorrectly displays on website and apps (those that show them even when they are hidden). But as it has been going on for a while now, the end users will think there is a problem with the app, unaware it is the data feed. Many users will be commuters who regularly use BHM and could start looking to other solutions for the information. Developers will lose users and possible revenue, whilst other may gain. 

The data feed itself has a recorded uptime, but the reliance on the data being available starts being questioned. 


I know there was a lot of rambling in this, and probably no really question. But thought it might raise a point or two. 

Tim

[Adam Williams]

> But as it has been going on for a while now, the end users will think there is a problem with the app, unaware it is the data feed

Exactly this. I have already had to explain that the Darwin data is broken for this station to multiple upset customers, and that the app we maintain is not at fault.

Yes, we can criticise the passengers and suggest they surely should've looked at departure boards/should've spoken to staff but it's not unreasonable for users to expect this to be working in 2026 for the biggest station in the country outside London, particularly if they've come to expect to get push notifications reliably or expect to be able to use built-in Live Times functionality with e.g. Android's TalkBack/VoiceOver on iOS. Requiring them to rely on staff when they might've otherwise been able to travel more independently is far from ideal. I would wager if they're having to make regular announcements at New Street about this to warn customers, then it's far from a triviality and is causing significant headaches on the ground.

I have just started telling affected customers to use Realtime Trains instead. At least we know that it will work (with the added bonus of avoiding unnecessary stampedes at stations like Euston).

Adam

[RailAleFan]

What's the status of Network Rail's own online departure board for Birmingham New Street (QR codes all over the station) - it's currently showing platform information contrary to the Darwin public view..?

[Tim Nightingale]

One thing we all might forget that having the data made available to us, for free, gives us chances to do things with it we might not normally get to do. 

There is no SLA agreement for the data, and as such efforts to solve might not be top of the pile. There may be an element of good will to get it resolved, but it wouldn't be a top priority. 

Yes National Rail, TOCs, others and many of us use it in solutions... but we have chosen to do that. The data quality is identified at 3 out of 5 by the publisher, so we shouldn't be surprised when things are not quite right. 

We have become too dependent on it and expect it to be fixed straight away. 

For passengers it is important that they catch their service and local station announcements should always be the recommendation when there is some uncertainty in the data. If the traveller ignores that advice, then is it an app or websites problem when that is put to them. 

Now if making the data available became a revenue stream, then there could be more focus on it, as SLAs would have to be met, RCA's provided for issues, and the quality score would improve. But how much are we willing to pay. 

Large organisations and their apps might easily be able to afford it, but it might price out the part-time and hobby developers who bring different ways of doing things, developing niche solutions that aren't trying to do everything and sell tickets on top. 

So, if there is an issue, what have you designed into your solution to let the user know? How do you gracefully inform them the national data feed would be affecting many solutions, and yours isn't failing. We shouldn't be pointing fingers of blame, but working together to see if we can build around little problems. 

There are already data fields nrccMessages, platformAvailable, areServicesAvailable returned in the DeparturesBoard object, perhaps an additional one indicating problems with the data could help? 

I don't know what the final solution will be, but I am happy to help where I can, which includes adding text to my solution informing users when to check local boards. 

Tim

[Tom Cairns]

I fundamentally disagree with that message entirely. This is simply not a matter of open data being wrong or otherwise.

The industry actively states that Darwin is the "one version of the truth" or “One Customer Message”. The reality is that it is “a truth” - not “the truth”. The industry spends a vast amount of money with a lot of different suppliers on this whole ecosystem and puts it at the core of its customer messaging. 

There are people in this very thread who are obliged to make Darwin work as part of their jobs. Darwin is a core part of retail - and the lack of information has caused complaints, has related in disruption to customer journeys, etc. Retailers provide a huge amount of money into the industry and, even if not directly, subsidise it. Even they rarely get RCAs. 

It is an important component of Passenger Assist, the entire service that makes is meant to help those needing assistance get around. If data that should be there is missing out of it, then it is affecting peoples journeys and that simply isn’t right. That’s potentially highly politically damaging if it happens to the wrong person and they find out why.

There are computer information screens (they look like a web page) on New Street station that are driven from Darwin, not the CIS, and they are beyond the gateline. I haven’t been to New Street to check, but my guess is that these are either wrong or not showing platform information. New Street has a lot of QR code posters which go to a system that RailAleFan mentioned, that’s showing platform numbers from Darwin I expect. Not checked - but assume that’s wrong.

Platform information isn’t a nice to have thing - it’s a critical part of the journey. Saying that it’s available on the station is all very well and good except there are going to be things on that station that are also wrong! There are information displays that are driven by Darwin, not the local CIS. 

This should never be a problem that lasts more than a few hours frankly. Unfortunately it’s fairly common in the industry that when a problem occurs it’s only considered within its own scope, and not the much bigger picture.

Tom 

--

You received this message because you are subscribed to the Google Groups "A gathering place for the Open Rail Data community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openraildata-t...@googlegroups.com.

To view this discussion, visit https://groups.google.com/d/msgid/openraildata-talk/82a50538-9841-4ca1-99e4-9a9515fcdad3n%40googlegroups.com.

[David Wheatley]

One thing we all might forget that having the data made available to us, for free, gives us chances to do things with it we might not normally get to do. 

There is no SLA agreement for the data, and as such efforts to solve might not be top of the pile. There may be an element of good will to get it resolved, but it wouldn't be a top priority. 

Yes National Rail, TOCs, others and many of us use it in solutions... but we have chosen to do that.

Some of us work in the industry, and report issues here just like hobbyists would, partly because sharing that information with other data consumers is useful for everyone, and partly because it's likely to get more eyes on here than through official channels sometimes!

 

The data quality is identified at 3 out of 5 by the publisher, so we shouldn't be surprised when things are not quite right. 

You mean the data quality section which reads "Not scored", and thus is showing the default rating? :P Besides, many of us aren't using Darwin via RDM for numerous reasons unrelated to this discussion.

We have become too dependent on it and expect it to be fixed straight away. 

I don't think having high expectations is a bad thing, do you? I don't think anyone expects issues to be fixed "straight away," but the amount of time this has gone on for is not ideal. The fact that it happens to numerous stations at varying intervals is surely a sign that something in the chain of systems—starting from the local CIS control and eventually connecting into Darwin—isn't working properly.

Given that data from Darwin is used for more than just open data projects, like for retail systems and by TOC platforms as you suggest, as well as to power NRE, and also to power on-station information screens which are not connected to the CIS (such as the freestanding kiosks) and also even passenger assist.

Now if making the data available became a revenue stream, then there could be more focus on it, as SLAs would have to be met, RCA's provided for issues, and the quality score would improve. But how much are we willing to pay. 

Large organisations and their apps might easily be able to afford it, but it might price out the part-time and hobby developers who bring different ways of doing things, developing niche solutions that aren't trying to do everything and sell tickets on top. 

I don't necessarily think a lot of people here are complaining about this from a hobbyist point-of-view, but rather that the same exact data is used throughout the rail industry (as I point out above!) so it's not like it's only affecting the open data users.

So, if there is an issue, what have you designed into your solution to let the user know? How do you gracefully inform them the national data feed would be affecting many solutions, and yours isn't failing. We shouldn't be pointing fingers of blame, but working together to see if we can build around little problems.
 

There are already data fields nrccMessages, platformAvailable, areServicesAvailable returned in the DeparturesBoard object, perhaps an additional one indicating problems with the data could help? 

I don't see a reason why an NRCC Message hasn't been provided for this already via LDB(SV)WS. It seems like the perfect place to raise this issue across all customer platforms simultaneously.

--

You received this message because you are subscribed to the Google Groups "A gathering place for the Open Rail Data community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openraildata-t...@googlegroups.com.

To view this discussion, visit https://groups.google.com/d/msgid/openraildata-talk/82a50538-9841-4ca1-99e4-9a9515fcdad3n%40googlegroups.com.

[Peter Hicks]

Hi Tim

On Thursday, 23 April 2026 at 22:33, Tim Nightingale <1timnig...@gmail.com> wrote:

One thing we all might forget that having the data made available to us, for free, gives us chances to do things with it we might not normally get to do.

There is no SLA agreement for the data, and as such efforts to solve might not be top of the pile. There may be an element of good will to get it resolved, but it wouldn't be a top priority.

I disagree.  An SLA frequently does not guarantee anything, it merely sets an expectation and focus for repair from both sides.  Failing an SLA often results, at best, in service credits for those impacted, which is usually a percentage of what you've paid for the time the service is degraded, and rarely more than what you've paid.

Think about Delay Repay - you get back up to 100% of the price you paid for a ticket if you're delayed and certain other criteria are met.  Often, the price you've paid for the ticket is small in comparison to the value of the journey to you, so it might not cover your own losses.

The Push Port and Live Departure Boards API data available on the RDM is exactly the same data that goes out to industry systems, but the means of access varies in order to protect the underlying systems.

Peter

[Tim Nightingale]

I can fully understand the points raised, they are valid. 

But if Darwin is promoted as 'the definitive data feed to use' then surely there would be some up-time target?

How are the consumers to know when there is an issue? For BHM then the platforms are hidden, but there is no field or message to indicate there is a technical issue upstream. 

People will naturally look for alternative ways to get the information, which is why 'expected' platforms may be used. The front end gets the blame and loss of trust very quickly, and they have no definitive way to say it isn't their fault. 

And just like the 'wheresmyplatform' solution. Is counting how many services had platforms assigned looking backwards the correct measurement? It still doesn't mean the platform was available for consumption - which then means we need to define what we are actually measuring and how. 

I am not having a go at Darwin or the people behind it, I am sorry if I have come across that way. I want to be able to trust it 100% and be aware of when there may be issues, and maybe not have to parse an HTML message field to find out. 

Tim

[Peter Hicks]

Hi Tim

On Saturday, 25 April 2026 at 12:30, Tim Nightingale <1timnig...@gmail.com> wrote:

But if Darwin is promoted as 'the definitive data feed to use' then surely there would be some up-time target?

There is - I'm not sure what it is, and the target will cover multiple different systems.  However, this is not a problem with Darwin - it is a problem of a station CIS not sending platform data to Darwin.  That will have its own contract and SLAs, unless something is out-of-support for some reason.

How are the consumers to know when there is an issue? For BHM then the platforms are hidden, but there is no field or message to indicate there is a technical issue upstream.

That point is valid, and I'm trying to find a contact at the station so they can get a station message put on reporting the issue.

And just like the 'wheresmyplatform' solution. Is counting how many services had platforms assigned looking backwards the correct measurement? It still doesn't mean the platform was available for consumption - which then means we need to define what we are actually measuring and how.

David's original codebase works well - it shows when Darwin hasn't had any confirmed (i.e. unsuppressed) platform numbers, which is a strong indicator that the control system at the station isn't connected to Darwin.  If you want to go further than this, i.e. not just adding other stations (e.g. Manchester, Birmingham New Street, Leeds, York, Liverpool, Glasgow, Edinburgh) then you need to understand what the code is doing, and the process behind it.

I am not having a go at Darwin or the people behind it, I am sorry if I have come across that way. I want to be able to trust it 100% and be aware of when there may be issues, and maybe not have to parse an HTML message field to find out.

Again, that is a valid point.  Letting people know there is a problem is much better than not, even if it's going to take a while for you to fix the problem.  Take UK Power Networks for example - if I lose power, I get a text message within about 15 seconds and follow-up texts.  Or Thames Water - the leak I reported next to my workplace was visible on a map and I had periodic text messages telling me what they were doing to resolve it.

I will suggest it the next time I speak to RDG about Darwin.

Peter

[Tim Nightingale]

Looking back into Davis code... it looks for services that have a platform number present in the field. There is nothing to check if the platform is shown as hidden (surpresssed) that I could spot. 

Now I understand that at stations like EUS they can be made available shortly before the departure time and hidden moments before too. The resulting record probably keeping the platformHidden field as true. 

This is why I was attempting to look at the logic a bit more and count services where the platform is there but not hidden. (https://nexttrains.co.uk/wheresmyplatform.html)

Of course this doesn't work for all scenarios, but the original code showed BHM as 100% with platforms, correct in the data, but they are also all marked as hidden too. 

Tim