Operational Calling Points

[zeinab....@gmail.com]

Hi,

We have come across a schedule in the Darwin feed where the origin and destination are operational points (OPOR, OPDT) but the stops in between are not (they are IP as opposed to OPIP). The actual train schedule from the Transport Services does include the origin and destination stops as non-operational however.

This is what we saw:

-<schedule trainCat="XX" toc="VT" ssd="2015-08-14" trainId="9G25" uid="P50422" rid="201502131712998">
<sc:OPOR wtd="14:03" ptd="14:03" act="TB" tpl="EUSTON"/>
<sc:PP tpl="CMDNSTH" wtp="14:05:30"/>
<sc:PP tpl="CMDNJN" wtp="14:06"/>
<sc:PP tpl="WLSDWLJ" wtp="14:09"/>
<sc:PP tpl="WMBY" wtp="14:10:30"/>
<sc:PP tpl="HROW" wtp="14:12:30"/>
<sc:PP tpl="WATFDJ" wtp="14:15:30"/>
<sc:PP tpl="BONENDJ" wtp="14:19:30"/>
<sc:PP tpl="TRING" wtp="14:22:30"/>
<sc:PP tpl="LEDBRNJ" wtp="14:25:30"/>
<sc:PP tpl="BLTCHLY" wtp="14:30"/>
<sc:PP tpl="MKNSCEN" wtp="14:31:30"/>
<sc:PP tpl="HANSLPJ" wtp="14:35:30"/>
<sc:PP tpl="WEEDON" wtp="14:42"/>
<sc:PP tpl="HMTNJ" wtp="14:49"/>
<sc:IP wtd="14:52:30" ptd="14:51" act="T " tpl="RUGBY" wta="14:50:30" pta="14:51"/>
<sc:PP tpl="RUGBTVJ" wtp="14:54:30"/>
<sc:IP wtd="15:03:30" ptd="15:02" act="T " tpl="COVNTRY" wta="15:01:30" pta="15:02"/>
<sc:IP wtd="15:14:30" ptd="15:13" act="T " tpl="BHAMINT" wta="15:12:30" pta="15:13"/>
<sc:PP tpl="STECHFD" wtp="15:19"/>
<sc:PP tpl="PROOFHJ" wtp="15:23:30"/>
<sc:OPDT act="TF" tpl="BHAMNWS" wta="15:26" pta="15:27"/>
</schedule>

Is this an anomaly or are we supposed to process such schedules as we would non-operational ones?

Would we in this case treat "RUGBY" as the origin and "BHAMINT" as the destination?

Many thanks,
Zeinab

[petermount]

When did you receive that one?

I've looked at my logs & I don't see that one at all. The one I did see was rid="201508173721792" which appears to be this schedule but it doesn't have any OPOR entries.

The other thing that's odd is the rid you have here, 20150213... it's usually the same date as when the train is running, that one appears to be for last February?

Peter

[zeinab....@gmail.com]

Apologies Peter, we found out that the schedule was not actually in the live feed as you rightly identified. Our test department have used some old data in creating some of their test cases and this one was miss-reported. Knowing the date forms the first part of the rid (which is obvious now I see it) is useful and should help us avoid similar mistakes again.

Is that a valid schedule though or would we never receive such schedules from Darwin?

Thanks again,
Zeinab

[Peter Hicks]

Hi Zeinab

The date currently forms part of the RID, but check the XML Schema Definition for the actual format, since it may change in future.

I'm not sure if that's a valid schedule or not, since it was hand-crafted as a test case.  Where possible, I've always used test data from real-life for test cases, but clearly mark them as test cases by - for example - using an operator code of 'TT', or timing points that are clearly test locations.

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

[petermount]

The schema just says the RID is a string max 16 characters, nothing else.

Peter

[Peter Hicks]

On 18 Aug 2015, at 19:06, petermount <peter...@gmail.com> wrote:

> The schema just says the RID is a string max 16 characters, nothing else.

Thought so… so probably safe to assume that, whilst it is currently a sort-of timestamp, it might not be in the future.

It’d be easier as a timestamp actually :-)


Peter