Problem with last Friday's Timetable CIF?

[petermount]

Has anyone noticed that the timetable CIF for Friday 10'th is missing a Tiploc entry?

I had noticed on Saturday that my update script failed due to not being able to find the tiploc CRKLDPS but I forgot about it until this morning, so I started a full fresh import this morning thinking I had missed out an update down the line.

However in the end it failed with the same tiploc being missing in the full export file, so something failed in generating Friday's update & full CIF's as it's missing that tiploc at the start of the file.

Here's the schedule that's causing the problem:

BSNL073651507041507040000010 PEE5J32    122788002 EMU319 100D                  O

BX         TLY                                                                  

LOLUTON   2236 00002  SL     TB                                                 

LIHRPNDN  2242H2249      000000001        OP                                    

LIHRPNDNJ           2249H00000000   FL                                          

LISTALBCY           2253 000000003                                              

LIRADLETJ           2257 00000000                                               

LIHDON              2301H00000000                                               

LIWHMPSTM           2304 000000003                                              

LIWHMPSJN           2304H00000000                                               

LICTRDJN            2306 00000000   SL                                          

LIKNTSHTN 2307H2315H     000000003        RM                                    

LICTRDJN 2          2316H00000000                                               

LIWHMPSJN2          2318 00000000                                               

LIWHMPSTM2          2318H000000002                                              

LICRKLWSJ           2319H00000000   GL                  1                       

LICRKLDER 2321H2321H     00000000         OP                                    

LTCRKLDPS 2326 0000      TF                                                   

Peter

[Peter Hicks]

Hi Peter

On 13 Apr 2015, at 14:28, petermount <peter...@gmail.com> wrote:

Has anyone noticed that the timetable CIF for Friday 10'th is missing a Tiploc entry?

I had noticed on Saturday that my update script failed due to not being able to find the tiploc CRKLDPS but I forgot about it until this morning, so I started a full fresh import this morning thinking I had missed out an update down the line.

That TIPLOC was created on 24th March, but deleted on 2nd April.  If I recall correctly, on TOPS, the TIPLOC for the location was changed.

This schedule (L07365) is the only one I can see timed at CRKLDPS, and it’s normally timed to arrive at CRKLDSS instead.  Both of these TIPLOCs are for STANOX 63415, so I think there’s been a problem somewhere when changing the TIPLOC record in CORPUS.

I don’t think this should happen - I’ll check with Network Rail.

Peter

[petermount]

Yes a grep of the CIF only shows that TIPLOC being in the file just once.

Peter

[Peter Hicks]

Hi Peter

I've chased this up and had a reply back - unfortunately, it doesn't look like there's strict referential integrity between the set of TIPLOCs and the set of timing points.

The safest assumption to make is that TIPLOCs included in LI, LO and LT records are not always included in TIPLOC records.

I think this is the only instance of this in the past 4-5 years I've been receiving schedule data.

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.

--

Peter Hicks  |  Poggs Consultancy Services  |  t: 020 3095 2600  |  m: 07970 476447

[petermount]

Thanks Peter, I'll modify my code to do what I'm doing with the darwin feed & generating a dummy entry for missing ones.

What I've done to get around this was to add a dummy record in the full CIF for that one & did a full import. It got around that problem for now.

Peter

[se...@cosine-systems.com]

Hi.

I've never posted on here before. I did a quick google search as this has been an ongoing problem for me too.

I have been reporting this to Network Rail's PSS team for about a month now and as of last night's full CIF file (12th of May 2015), the CRKLDPS tiploc appeared on 120 trains in the file and it is still not being pushed as an insert location.

My own software will decode the CIF data OK, but when it finds a tiploc it doesn't know, it drops the row of data so I will have 120 trains which are missing an origin or termination location as these tiplocs always appear as an origin or terminating location. I'm not happy to have incomplete trains inside my database and hope this will be resolved sometime sooner rather than later.

Apart from this past month that this has been happening, it is the second time that such an occurrence has happened over the last 18 months. The previous time it happened, I requested a full CIF file again and the problem had vanished. There's obviously no form of error checking between the entire list of tiplocs and the train schedules being pushed by ITPS.

Sean

[Peter Hicks]

Hi Sean

There’s not really much we can do from a community point of view, but what about modifying your software to either:

a) Not require TIPLOCs in the schedule have a corresponding TIPLOC record from CIF
b) Manually add CRKLDPS in to your system and treat this as one-off

I don’t think the CIF spec explicitly says that TIPLOCs referenced in schedules will be included in TI records. I suspect there’s some kind of synchronisation issue between ITPS and the system that generates CIF data from ITPS - I found what I thought was a problem with associations and TIPLOC ‘instances’ (for repeated TIPLOCs) that we couldn’t get to the bottom of, but only happened once.


Peter

[se...@cosine-systems.com]

Hi Peter,

I have an area within my database where a location with multiple tiplocs (such as Clapham Junction which has 6) can be merged together. I created an entry to merge CRKLDPS with CRKLDSS as it seems to be the same location from what I've been reading on this thread.

My decoder is most of the way through last night's CIF file (403Mb) and no missing tiplocs have been reported. It will be another 20 minutes or so before the processing is complete and all data caches will have been rebuilt.

Sean

[Peter Hicks]

Hi Sean

On 13 May 2015, at 11:13, se...@cosine-systems.com wrote:

> I have an area within my database where a location with multiple tiplocs (such as Clapham Junction which has 6) can be merged together. I created an entry to merge CRKLDPS with CRKLDSS as it seems to be the same location from what I've been reading on this thread.

Those TIPLOCs are all distinct locations - so be careful when merging them together! For example:

CLPHMWJ - Windsor Lines
CLPHMJM - Main Lines
CLPHMJ1 - London Overground platforms

What you probably want is a mapping between CRS codes - CLJ has a single CRS code which covers multiple TIPLOCs, as CRS codes are used for passenger information rather than train planning.



Peter

[Paul Kelly]

se...@cosine-systems.com wrote:
>
> I have been reporting this to Network Rail's PSS team for about a month now and as of last night's full CIF file (12th of May 2015), the CRKLDPS tiploc appeared on 120 trains in the file and it is still not being pushed as an insert location.

It *was* inserted on 24th March (as "CRICKLEWOOD SOUTH SIDINGS" with a
STANOX code of 63415), but then deleted again on 2nd April.

> My own software will decode the CIF data OK, but when it finds a tiploc it doesn't know, it drops the row of data so I will have 120 trains which are missing an origin or termination location as these tiplocs always appear as an origin or terminating location. I'm not happy to have incomplete trains inside my database and hope this will be resolved sometime sooner rather than later.

Why not do a first scan through each CIF extract to index all TIPLOC
codes that occur in schedules - then they will always be "known" when
you read the schedule data in the second pass?

Paul

[se...@cosine-systems.com]

I don't really want to scan the data first to verify what the tiploc insert information contents are correct. I also don't load the CIF file into memory in one go, but only read it on a line-by-line basis, build normalized tables in memory that get committed to the database.

You will notice that from this morning, CRKLDPS is back in the CIF data. I had confirmation from Network Rail yesterday that there were numerous other errors in the CIF data that other users were reporting. The CRKLDPS tiploc was meant for use at the start of the Summer May 2015 timetable (17th of May 2015) so is valid from this Sunday.

Sean