TD Obfuscation and Headcodes

95 views
Skip to first unread message

Matthew B

unread,
Mar 3, 2020, 2:08:19 PM3/3/20
to A gathering place for the Open Rail Data community
I've been doing quite a bit of work with the TD information recently on my website.
One thing I have noticed; is that quite a few services run on the TD feed with an obfuscated headcode different to that on the TRUST feed.
Why is this?
Some days I open up opentraintimes maps, see an obfuscated headcode, and pop it into my websites obfuscode schedule search and either it can't find it, or it's a completely unrelated service.
And tonight, 132K Tonbridge to London Bridge is shown on trust feed as 132K as 143K (is it coincidence or can I just add on a 1 to the second and third digits in the trust obfuscode :P )
Is this some sort of bug that would be worth bothering emailing CACI about?
I haven't been too bothered about the TD until lately, given the amount of services that "drop off" the TRUST feed, especially rhtt and test trains, before showing as "741 minutes early" soon after...I am now using the TD info for additional reporting metrics and was wondering why this happens , a obfuscated headcode doesn't match up to the trust one in some cases.

Peter Hicks

unread,
Mar 3, 2020, 2:25:20 PM3/3/20
to A gathering place for the Open Rail Data community
Hi Matthew

The obfuscation mechanism isn't reliable when there are two or more trains running with the original reporting number.

The train that appears as 132K (let's call it 1Q00) was manually called at 1204 and so any description in the TD feed of 1Q00 would be replaced with '132K'.  This is all good until 1837, then another manual train call was made for another train running under 1Q00 elsewhere in the country.  This set up a separate obfuscation mapping of 143K, so any 1Q00 in the TD feed is now replaced with 143K.

This non-determinism is fine, because obfuscation isn't a simple case of "Replace the reporting number with something else" - it's supposed to make it difficult to determine all details of the service.  Knowing there is *a* train moving between signals is better than not knowing there's a train there - it paints a bad picture if you see successive signals turn to danger with no TD message.

Anyway, the best solution for this is for the industry not to treat train reporting numbers as a pseudo-secret.


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 view this discussion on the web, visit https://groups.google.com/d/msgid/openraildata-talk/221ff1a1-11f9-4e5f-b24b-592fdadd4aaf%40googlegroups.com.


OpenTrainTimes Ltd. registered in England and Wales, company no. 09504022.
Registered office: 13a Davenant Road, Upper Holloway, London N19 3NW

Matthew Burdett

unread,
Mar 3, 2020, 2:28:59 PM3/3/20
to openrail...@googlegroups.com
Thanks Peter, that makes sense.
Kind regards.

You received this message because you are subscribed to a topic in the Google Groups "A gathering place for the Open Rail Data community" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openraildata-talk/sABIN2BwFuE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openraildata-t...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openraildata-talk/CAKGkhzbj0awYJHAV8GQFBstbrnjLMsBMVkFiiUGxauYrL2AarA%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages