Berth SSH108

[Russell Bowman]

I wonder if someone who knows about these things can suggest what's happening with this sequence in the TD feed.

I have a Berth Sniffer process which spends it's time monitoring the TD feed building a berth and connections database, and identifying cases where, at TD boundaries, the same 'physical' berth is reported under two or more berth names.  It keeps telling me that the following two berths are the same.  On the face of it, its evidence is clear, but geography says otherwise. (I have some geographic logic which triggers it to report cases like this.)

SS H108 (36080 Liverpool Cntrl) and 

M3 G036 (36719 Glazebrook)

A dump of the TD feed with an example of the evidence (and there are several sequences like this for different describers) is below.

Time	Type	Desc	Area	From	To
28/01/2019 08:11	CA	2O71	M3	M3G037	M3G036
28/01/2019 08:16	CA	2O71	M3	M3G036	M3GW02
28/01/2019 08:16	CA	2O71	XE	XESTIN	XE0002
28/01/2019 08:16	CA	2O71	XL	XLSTIN	XLW002
28/01/2019 08:16	CB	2O71	SS	SSH108
28/01/2019 08:21	CA	2O71	XE	XE0002	XE0003
28/01/2019 08:21	CA	2O71	XL	XLW002	XLW003
28/01/2019 08:21	CA	2O71	M3	M3GW02	M3COUT
28/01/2019 08:22	CA	2O71	XE	XE0003	XE0004

(I checked and there were no other instances of describer 2O71 running at the time.)

In what is a messy sequence of steps getting itself from the M3 area to (I think) the XL area (eventually), there is a spurious CB message thrown in there for berth SS H108.  I've checked all the steps for 2O71 and it never actually steps into the SS area another time.  Whilst the XL area does (I think) link to the SS area, it doesn't happen anywhere around any of the berths above.

I don't know how this all ties up at the backend, but somewhere there must be a mapping of overlapping berths at TD boundaries.  Could this just be triggered by some key error? (although I imagine it's more complex).

Russell

(PS If no one knows the answer, that's fine, the Berth Sniffer logic catches it just fine and ignores the apparent match.)

[Tom Cairns]

I’ve mostly calculated matching berths at boundaries partially using an algorithm using a similar process to you.

 

My database does not align SS H108 with any active berth on the network at present - but that general area is a bit of a mess as I recall. I tend to match berths together based on steps rather than berths themselves, though.

 

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

[Thomas Wood]

It looks like XL (Hunt's Cross) is repeating all of the berths on XE (Warrington Central).

SS H108 is used as the last sent berth on Sandhills IECC on the Down Southport from Liverpool Central, and is repeated from Hunt's Cross. It would appear that Hunt's Cross is incorrectly cancelling out the external H108 berth. Likely a bug or typo in the stepping tables?

Regards,

Thomas

[Russell Bowman]

Thanks both for the info.

On Tuesday, 29 January 2019 22:11:00 UTC, Russell Bowman wrote: