Home » railML newsgroups » railml.timetable » Timetable updates
Timetable updates [message #571] |
Thu, 08 April 2004 14:38 |
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 #575 is a reply to message #574] |
Wed, 14 April 2004 09:29 |
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 |
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 |
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 |
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
>>>> >>>
>>>> >>>
>>>> >>
>>>>
>>
>>
|
|
|
Goto Forum:
Current Time: Wed Oct 02 11:41:24 CEST 2024
|