Home » railML newsgroups » railml.timetable » Timetable updates
Timetable updates [message #571] Thu, 08 April 2004 14:38 Go to next message
tobias is currently offline  tobias
Messages: 8
Registered: April 2005
Junior Member
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
Re: Timetable updates [message #572 is a reply to message #571] Thu, 08 April 2004 15:10 Go to previous messageGo to next message
Joachim.Rubröder is currently offline  Joachim.Rubröder
Messages: 33
Registered: September 2004
Member
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
>
>
Re: Timetable updates [message #573 is a reply to message #572] Tue, 13 April 2004 14:57 Go to previous messageGo to next message
thomas.kauer is currently offline  thomas.kauer
Messages: 15
Registered: January 2004
Junior Member
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.



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
>>
>>
Re: Timetable updates [message #574 is a reply to message #573] Tue, 13 April 2004 17:26 Go to previous messageGo to next message
tobias is currently offline  tobias
Messages: 8
Registered: April 2005
Junior Member
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
>>>
>>>
Re: Timetable updates [message #575 is a reply to message #574] Wed, 14 April 2004 09:29 Go to previous messageGo to next message
Joachim.Rubröder is currently offline  Joachim.Rubröder
Messages: 33
Registered: September 2004
Member
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
>>>>
>>>>
>>>
>
>
Re: Timetable updates [message #576 is a reply to message #575] Wed, 14 April 2004 11:15 Go to previous messageGo to next 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
>>>> >
>>>> >
>>>>
>>
>>
Re: Timetable updates [message #577 is a reply to message #576] Thu, 22 April 2004 14:31 Go to previous messageGo to next message
Joachim.Rubröder is currently offline  Joachim.Rubröder
Messages: 33
Registered: September 2004
Member
So I suggest to form a new group of attributes for the train:

<dataSource> the former <source>
<dataDateTime> the former <date>, now with expanded type "dateTime"
<dataStatus> new data, changed data, deleted data, ...

in addition there will be the two new attributes

<trainNumber> the train number (not unique)
<trainStatus> planned train, canceled train, ...

I think this should solve the problems about "Timetable updates"?
best regards,

J.Rubröder



Thomas Kauer schrieb:
> 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
>>>> >>
>>>> >>
>>>> >
>>>
>
>
Re: Timetable updates [message #578 is a reply to message #577] Fri, 23 April 2004 08:35 Go to previous message
thomas.kauer is currently offline  thomas.kauer
Messages: 15
Registered: January 2004
Junior Member
I think that should do it.

best regards
Thomas Kauer



Joachim Rubröder wrote:

> So I suggest to form a new group of attributes for the train:

> <dataSource> the former <source>
> <dataDateTime> the former <date>, now with expanded type "dateTime"
> <dataStatus> new data, changed data, deleted data, ...

> in addition there will be the two new attributes

> <trainNumber> the train number (not unique)
> <trainStatus> planned train, canceled train, ...

> I think this should solve the problems about "Timetable updates"?
> best regards,

> J.Rubröder



> Thomas Kauer schrieb:
>> 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
>>>> >>>
>>>> >>>
>>>> >>
>>>>
>>
>>
Previous Topic: Daylight saving time
Next Topic: [Proposal]
Goto Forum:
  


Current Time: Thu Mar 28 10:23:25 CET 2024