JSON format schedule update failed?

[Russell Bowman]

The schedule files on the Wed link (i.e. what should be the latest) are a week old, sequence 2149, rather than 2155 as expected.

Support ticket raised.

Russell

[Russell Bowman]

...and again today no JSON schedule update file.  I think the CIF format file looks correct.  I really am going to have to rewrite to take the CIF format file!

[Mark Wherity]

Seeing the same thing here - the last time a JSON version of the timetable (either update or full) was published was Tuesday night.

[WantStuff]

Same here.

Weds, Thurs and Fri are the same files

On Thursday, 10 May 2018 06:37:09 UTC+1, Russell Bowman wrote:

[Nick Lamb]

is this related to the issue I posted about, I trawl through https://hsp-prod.rockshore.net/api/v1/serviceDetails which I believe is in JSON format to gather details of all Southern Thameslink and Gatwick Express trains using a key of date and rid - all days work apart from the 10th May
today (11th) looks okay

[WantStuff]

These are the NROD (Network Rail) nightly files, not the Darwin (National Rail) stuff.

[Mark Wherity]

Still no new JSON format timetable files today.

Russell, did you hear back on the support ticket you raised?

[Russell Bowman]

No, not a word. I *think* the CIF format is being created ok, but I’m loath to rewrite the interface. Ill look to chase the support ticket in the morning.

[Russell Bowman]

It's ticket #2018051000000224.  Sent a request for an update.

On Thursday, 10 May 2018 06:37:09 UTC+1, Russell Bowman wrote:

[Dave Burbridge]

So, a week of no json updates, and no official word. Are json updates dead? in which case I'm also going to have to rewrite to use the CIF format - a pain as the data's laid out differently and definitely not object-oriented!

[Michael Flynn]

Open data is a fantastic resource but it has major short-comings.  This issue is just another example.  If it was a commercial environment you would simply move on and find another supplier.  

I don't envy you have to rewrite in CIF.  I'm the other way round, I'll be looking at a rewrite/plan B if/when they drop support for CIF.  Even, as in this case, it's probably just a short-term thing.  But how long can you wait?

Mike

On Thursday, 10 May 2018 06:37:09 UTC+1, Russell Bowman wrote:

[WantStuff]

To be honest, I have plans to load all the available forms of data and then consume it on my perceived system priority basis. This certainly isn’t the ideal way as it means a certain amount of repeated or similar code, but there always seems to be one system down/delayed.
This would also grant tolerance to my own infrastructure or coding failures.

[Mark Wherity]

I've sent a note to dsg_nrod...@caci.co.uk in case another follow-up helps prompt a response.

It seems unlikely that the JSON format would simply be dropped, but as you say Mike, it's a question of how long we're willing to wait for it to be acknowledged/fixed.

Mark

[David Higginbottom]

All,

We are aware of the issue with the schedules file and the engineers hope to resolve this today.

Apologies for any inconvenience.

Kind regards

Dave

[Russell Bowman]

Thanks for the update.   I started coding to read the CIF file this morning... only got as far as checking the header, but would much prefer to stick with the json feed if the recent issues can be resolved. :)

[Michael Flynn]

>>  I have plans to load all the available forms of data and then consume it on my perceived system priority basis.

My long-term strategy too!  Is a well-proven design strategy separating as far as possible the data, logic and UI.  

 

>> I started coding to read the CIF file this morning... only got as far as checking the header, but would much prefer to stick with the json feed if the recent issues can be resolved. :)

And just to make matters worse CIF is SO old-fashioned I guess it's days have got to be numbered too :{

[Peter Hicks]

Hi Michael

Please don't insinuate that Network Rail are, or will, or even might be discontinuing production of schedule data in CIF format - all this does is scare people.

Just because it's "old fashioned" doesn't mean it's going to disappear, or that it's unsuitable for use.

Peter

--
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 post to this group, send email to openrail...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

OpenTrainTimes Ltd. registered in England and Wales, company no. 09504022.

Registered office: 13a Davenant Road, Upper Holloway, London N19 3NW

[Michael Flynn]

>>And just to make matters worse CIF is SO old-fashioned I guess it's days have got to be numbered too :{

     >> Please don't insinuate that Network Rail are, or will, or even might be discontinuing production of schedule data in CIF format - all this does is scare people.

Whoah, steady Peter!  That code is out of the 80's!!

[Juhani Pirttilahti]

CIF seems to be tied with so many proprietary railway systems that we won't get rid of it anytime soon.

Personally I'm fascinated to see anything originating from 1980's still in use. It is still better than punch cards anyway.

Just my 2 cents.

[Peter Hicks]

The CIF *spec* was drawn up in the 1980s, but the system that generates the files is, I believe, much more modern and not mainframe-based.

Incidentally, what's everyone's thoughts on other timetable formats that would be a replacement for CIF?  When I reviewed them all a few years ago, almost everything didn't support some of the train data in CIF, such as activity codes, allowances, service codes, etc.

Peter

--
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 post to this group, send email to openrail...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Flynn]

>> CIF seems to be tied with so many proprietary railway systems that we won't get rid of it anytime soon.

I guess so too.  But sticking with backward compatibility for so long just ties things up.  I think they've got to grasp the nettle at some stage and drop CIF completely.  If they do though I for one would need some notice.  Hopefully it gets flagged on the forum too though as I often don't get anything by email.

>> Personally I'm fascinated to see anything originating from 1980's still in use. It is still better than punch cards anyway.

Me too.  Reminds me when I started out as a programmer.  I could tell you the story when my boss brought in a pack of punch cards and feigned dropping them... actually, no I'll save you that one!

>> Incidentally, what's everyone's thoughts on other timetable formats that would be a replacement for CIF?

There's many formats out there.  I would be impressed if one of more modern standard formats were used, the obvious one being GTFS.  Often though the powers to be can be seduced into thinking if it's obscure and difficult to use they'll be able to keep their expertise to themselves.  Plumbing springs to mind as an example of this.

[Phil Wieland]

I thought it was punched cards!  Why else would it be arranged in 80 columns?

[mi...@a1publishing.com]

... so the boss and his pal has tricked me into getting the cards all out of sync and they're needed for the batch run that night otherwise they're going make me personally punch a set myself but the person who knows how to use the machine was in a meeting all day.... LOL

[Chris Bailiss]

Hi Peter

I chose to consume the CIF format, simply because it is closer to the format the railway uses.  I took the judgement call that so many railway systems use it, it is likely to be the least volatile over time.  It also contains some data not in the JSON format.

I'm still happy consuming CIF and hope the Open Data platform retains support for this until the railway itself moves onto another format.

Chris

[Peter Hicks (Poggs)]

Hi Chris

> On 20 May 2018, at 11:58, Chris Bailiss <cbai...@gmail.com> wrote:
>
> I chose to consume the CIF format, simply because it is closer to the format the railway uses. I took the judgement call that so many railway systems use it, it is likely to be the least volatile over time. It also contains some data not in the JSON format.
>
> I'm still happy consuming CIF and hope the Open Data platform retains support for this until the railway itself moves onto another format.

I think you’re spot on in your decision. For Network Rail to stop producing CIF will be expensive for the entire industry and will not happen overnight. Given the pace of change in the industry, I anticipate that if it *did* happen, it’d take at least a year after the new format were available for the older format to be deprecated - if it was at all.

What I can see happening in the next year or three is that data in a new format is produced, containing additional information not currently available in CIF. For example, the Traffic Management programme may require that new-format OTNs (operational train numbers) are assigned to trains - these could be supported in CIF through an extra field in the ‘BX’ record, but I wouldn’t be surprised if a completely new format was introduced in parallel, containing exactly the same basic information as well as new.

I also strongly believe that rather than anyone worrying about the long-term plans for schedule data, that they actually start consuming what’s available and doing something with it. It’s very easy to get carried away with “what could happen”, or talking about everything you’re planning to do in the future - there’s more credibility in showing what you’ve done than coming up with loads of ideas that don’t see the light of day.



Peter


--

[Mark Wherity]

Dave - thanks for the team's work to resolve this.

On Wednesday, 16 May 2018 08:31:48 UTC+1, David Higginbottom wrote:

[Guido Eco]

On Wednesday, 16 May 2018 10:02:19 UTC+1, Peter Hicks wrote:

Hi Michael

Please don't insinuate that Network Rail are, or will, or even might be discontinuing production of schedule data in CIF format - all this does is scare people.

Just because it's "old fashioned" doesn't mean it's going to disappear, or that it's unsuitable for use.

Peter

Hi,

I would echo this. The CIF file format or any other message feeds will go anywhere in the next 20 years. However, I suspect additional alternative data exchange and formats are likely to emerge and more so with train operations messages.

If I were to take a wild guess I suspect that, with the introduction of Traffic Management Systems under Digital Railway, for operational data exchange there will be more alternatives offered around and that will consist of an xml based interface similar to the the Telematic Applications for Freight and Telematic Applications for Passenger Services specification.

There is a discussion about message data header format buried in the minutes of the TAF TAP Senior User Group (SUG) 14 September 2017. (https://cdn.networkrail.co.uk/wp-content/uploads/2017/12/14-September-2017-UK-TAF-SUG-Meeting-Minutes.pdf). In this the proposal is that the "headcode" will be maintained as the OTN but that the unique combination of TPS Schedule UID and *scheduled date* of departure is likely to be used to maintain the link with planning and that the message will also contain the TRUST UID following train call.

Guido

[Dave Burbridge]

There seems to be a problem again - I've only just noticed, but the JSON format update for last Tuesday (10th July, sequence number 2218) never seemed to have been uploaded. I just keep getting the one for 3rd July (2211).

It remains to be seen whether we get 2225 or 2211 tomorrow morning...!

[Russell Bowman]

I loaded 2224 as expected this morning. There was one skipped a few days ago, but I reloaded from the full dump, and all was well the next day.

I would have reported it but I have some health issues at the moment.

Russell

[Dave Burbridge]

2225 arrived this morning, so we're just missing 2218. And gained a whole bunch of errors due to later updates referring to things in 2218 that we don't know about...!

D