| 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
>>>> >>>
>>>> >>>
>>>> >>
>>>>
>>
>>
|
|
|
|
Members
Search
Help
Login
Home
