Home » railML newsgroups » railml.timetable » Timetable updates
Re: Timetable updates [message #576 is a reply to message #575] Wed, 14 April 2004 11:15 Go to previous messageGo to previous message
thomas.kauer is currently offline  thomas.kauer
Messages: 15
Registered: January 2004
Junior Member
I agree that we need a technical trainID that is independent of the
"outside" used train number.
On european level there is a project in work to follow international
trains between NL and I passing the alps (Europtirails). For this there
will be introduced a global trainID over all the way the train runs (over
all companies and countries) to which the locally used train numbers have
to be associated.

Actually the idea is to use a combination of:

- the train number at the beginning of the train
- the departure station
- the departure day/time (important since such trains can run for
more than 24h)

but there is no final format defined yet as far as I know.

The <status> would be needed not to identify the train but as additional
information.
By the way, I see at least two kinds/groups of informations that could be
treated as status:
- information about the train (running, canceled, planned, ...)
- information about the data (as suggested below: new data/train,
changed data for an excisting train, ...)

best regards
Thomas Kauer


Joachim Rubröder wrote:

> I agree that a trainID like "4712" is not enough to identify a train.
> For german DB we use a combination of line number, train number,
> operating period and the timetable period as trainID and there are still
> some identification problems to solve.

> What abuot:

> <trainID> technical ID to identify a train, used by the programs
> (most often based on the train number)

> <trainNumber> new element for the train number, as used by railways
> like "4712"

> <status> as suggested below, like "changed"

> <date> with new ISO8601-format xsd:dateTime instead of
> xsd:date (a date with optional time, fractional seconds up to
> nanoseconds are possible like "19941105T08:15:00301")

> best regards,
> Joachim Rubröder



> Tobias Bende schrieb:
>> Thomas Kauer wrote:
>>
>>
>>> In respect to possible future use of the timetable-schema as an interface
>>> for programs that treat with actual trains and not only with longtime
>>> planning it should support the possibility to give delta-informations for
>>> existing timetable data. So it would be useful to add the proposed
>>> attribute <status>.
>>> The <date> of the last change would be used in this respect to decide for
>>> multiple changes which one is the last, that is to say which one is valid.
>>
>>
>>
>> An example where one would definitely need delta-information is a
>> day-of-operation system for railway companies. In such a system there
>> would be several updates per second.
>>
>> It has to be asked if the <status> attribute is adequate for indicating
>> changes. It could be if there existed some identity for each train, but an
>> artificial identity (like train number + date) is not enough. For example,
>> how would I send the information that train number 4711 is now called
>> 4712?
>>
>>
>>
>>
>>> Joachim Rubröder wrote:
>>
>>
>>>> This case is not especially treated in the schema. But you are free to
>>>> put a whole big timetable with thousand trains in a file, or to send
>>>> just a few update-trains. I think this is a task for the receiving
>>>> program to identify the trains as new or known ones.
>>>
>>
>>>> There is the <date> attribute in <train> which could be used as date of
>>>> the last change and I thought about adding another optional attribute
>>>> <status> in the <train> element (as used within SBB) wich could have
>>>> values like "new", "changed", "omitted", ...
>>>> Would this be helpful?
>>>
>>
>>>> Joachim Rubröder
>>>
>>
>>>> Tobias Bende schrieb:
>>>>
>>>> >I have a question on updates of existing timetables. Given that a file
>>>> >with a complete timetable (especially in a format like RailML) is very
>>>> >large it is in practice often desirable to be able to send updates when
>>>> >something changes as opposed to recreate and send the entire file. Is
>>>>
>> this
>>
>>>> >something that has been considered?
>>>> >
>>>> >Tobias Bende
>>>> >
>>>> >
>>>>
>>
>>
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Daylight saving time
Next Topic: [Proposal]
Goto Forum:
  


Current Time: Fri Mar 29 02:42:54 CET 2024