TD Area in td messages

[Adrian Hooper]

I'm trying to get my head around mapping TD areas and trains within them, and had a couple of questions around the TD feed messages and the td area.

1) Am I right in assuming that for general operation of a service (standard passenger), that basically all messages are likely to be CA? Are there any reasons why there would be CB or CC messages?

2) How common is it for a service to span multiple TD areas?

3) In the CA message, am I right in thinking that the "area-id" field applies to the berth in the "to" field and not the "to"?

My query around question 2 + 3 is that, in the event of a train passing from one TD area to another, either the "from" or "to" field in the CA message would be half useless would it not, given that a berth identifier is only unique for a given TD?

Hopefully that all made sense.

Cheers

[Adrian Bradshaw]

It's a while since I did this - I'm sure someone will correct me if I'm wrong.....

 

CA messages are a movement from one berth in a TD area to another in the same area.

CB messages are a "clear-out" messages - used mostly when a train leaves a TD area

CC messages are received when a train first enters a TD area

 

It's not *quite* that simple, but basically, you need to deal with all three.... 

 

Berths numbers are unique within a particular TD area. When a train moves out of one TD area you will get a CB message and a corresponding CC message to continue its journey in the new area.

 

Cheers,

Adrian

---

Adrian Bradshaw – Administrator (volunteer)

Railcam UK Limited

@: adr...@railcam.uk

Railcam.uk – Bringing The Lineside To Your Armchair

Railcam UK Limited | A company limited by guarantee | registration number 10167844

3rd Floor | 207 Regent Street | London W1B 3HH

Railcam UK Ltd is operated on a not-for-profit basis entirely by volunteers

--
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.

[Adrian Hooper]

Ah ok, so lets say a train is running from A -> B that spans two TD areas, I would effectively get:

- CA

- CA

- CA

- CB (leaving TD)

- CC (entering TD)

- CA

- CA

... and so on

Are there any/many scenarios where this isn't the case that I should know about? I know (at least I think) that the CB and CC messages can also be sent when a train leaves the network, such as going into sidings, but I guess that's kinda the same as leaving and entering a TD area?

[Mike Playle]

On Tuesday, January 10, 2017 at 1:08:48 PM UTC, Adrian Hooper wrote:

Ah ok, so lets say a train is running from A -> B that spans two TD areas, I would effectively get:

- CA

- CA

- CA

- CB (leaving TD)

- CC (entering TD)

- CA

- CA

... and so on

Are there any/many scenarios where this isn't the case that I should know about?

Sometimes TD areas "overlap" each other. In this case some berths are effectively displayed in both TD areas and you'll see a train enter the new area and perform several steps in both areas together before leaving the old area.

Some regions of the railway have no TD coverage. In this case a train might disappear from one TD area long before it appears in the next. The Oakham/Stamford/Melton Mowbray area between Peterborough and Leicester behaves like this. I'm sure there are other places where this happens, too.

Not all TD berths represent physical locations on the railway. Sometimes when a train leaves an area it'll still be shown in a "last sent" berth in that area for some time afterwards.

[Mike Playle]

On Tuesday, January 10, 2017 at 1:08:48 PM UTC, Adrian Hooper wrote:

- CB (leaving TD)

- CC (entering TD) 

Oh, and some TD areas will send steps from the STIN berth or to the COUT berth, rather than CB or CC messages.
 

[petermount]

A good example is one that's just gone from ME (Maidstone East) to A2 (Ashford) a few minutes ago:

{"CA_MSG":{"to":"M223","time":"1484055971000","area_id":"MA","msg_type":"CA","from":"M217","descr":"2N34"}}

{"CA_MSG":{"to":"COUT","time":"1484056049000","area_id":"MA","msg_type":"CA","from":"M223","descr":"2N34"}}

{"CC_MSG":{"to":"0851","time":"1484056049000","area_id":"A2","msg_type":"CC","descr":"2N34"}}]

{"CA_MSG":{"to":"0663","time":"1484056139000","area_id":"A2","msg_type":"CA","from":"0851","descr":"2N34"}}

This one's just gone from berth M217 to M223 to COUT in area ME (Maidstone East) and at the same instant it went into COUT before 0851 then 0663 in A2 (Ashford IECC B

)

ME http://uktra.in/signal/map/MA

A2 http://uktra.in/signal/map/A2

Peter

[Adrian Bradshaw]

Adrian

Almost...

There will always be a CC message which will introduce the headcode at
the
service origin.

Likewise, at the end of its journey, a CB message will remove the
headcode
from the TD area. Sometimes that will be immediately replaced with a
new CC
message for the service which the stock is next used on.

At the fringes of TD areas, things can get a bit messy. The Train
Describer
equipment which originates all this data is of varying vintage, from
the
1970s (?) onwards and they don't all behave the same. At adjoining TD
areas, you sometimes get the same berth (or multiple berths)
duplicated.
Off the top of my head, I don't know a real example, but you get
situations
like :

TD Train progressing through Berths - >
AA 0001 0003 0005 0006 0007 0009 B501 B502 COUT
BB XXXX A007 A009 5501 5502 5503 5505 5506

In this example, a train will appear in multiple berths simultaneously
- one on the AA describer and one on the BB describer. The duplicated
berths usually have the same last 3 digits, with a prefixed letter to
relate them to the adjoining describer - IE AA 0009 is duplicated as BB
A009.

In practice, this doesn't matter too much as long as you realise that
they are duplicates and don't try to plot both on a diagram, which
straddles more than one TD. I ended up writing software to monitor a
particular headcode on the feed to see how it behaved at the edges of TD
areas.

I hope that helps...
---

_Adrian Bradshaw - Administrator (volunteer)_

_Railcam UK Limited_

_@: adr...@railcam.uk_

_____RAILCAM.UK - BRINGING THE LINESIDE TO YOUR ARMCHAIR_

Railcam UK Limited | A company limited by guarantee | registration
number
10167844

3rd Floor | 207 Regent Street | London W1B 3HH

Railcam UK Ltd is operated on a not-for-profit basis entirely by
volunteers

>> _Adrian Bradshaw - Administrator (volunteer)_
>>
>> _Railcam UK Limited_
>>
>> _@: adr...@railcam.uk_
>>
>> _____RAILCAM.UK - BRINGING THE LINESIDE TO YOUR ARMCHAIR_

>>> For more options, visit https://groups.google.com/d/optout [1].


Links:
------
[1] https://groups.google.com/d/optout

[Adrian Hooper]

ha wow ok. I've got some code to figure out now, think I've mostly got my head round it now.

I'll take a crack at getting this sorted out, but I may well be back with more questions.

Thanks guys :)

[Rail Ale Fan]

Just to add to the knowledge base, another duplication scenario appears to be where a ROC has taken over (or maybe in the process of taking over) control of a legacy area ID, reports are received from both.  For example, when I was last capturing TD data duplicate reports would be received from WJ / Wembley Mainline (Watford) WestCAD and R1 / Rugby SCC (Watford - Bletchley ITD).

HTH!
--
https://live-departures.info/rail/