Home » railML newsgroups » railml.timetable » RailML semantics, nextdeparture, recurringschedule
Re: RailML semantics, nextdeparture, recurringschedule [message #731 is a reply to message #729] Wed, 11 May 2011 16:58 Go to previous messageGo to previous message
Joachim Rubröder railML is currently offline  Joachim Rubröder railML
Messages: 0
Registered: November 2019
Dear Tuomas,
this is a very strange and interesting concept.

A passenger would ask a timetable: "When leaves the next train from here
to xy?"
(-> connection)
A train driver could ask the vehicle: "Where are you supposed to go next?"
(-> blocks)
Anyone could ask a railway map: "Where could I go from this station?"
(-> infrastructure)
A commercial train could be asked: "What is published as your next
station?"
(-> train)
A train driver could ask the train: "What is our next station in the
timetable?"
(-> train)

What is the use case for the choice?
Why is the train driver asking such a question?

Train drivers and vehicles usually have their fixed service plans and the
physical trains have their fixed timetable to fulfill - there is no choice.

Your train drivers question sounds like a taxi driver asking about
possible further rides. Maybe it is the train asking "where shall we go
on?" by providing a list of possibilities (-> operational trains) with a
filter function. Then the train driver would choose the correct one,
because he knows it. But I would assume that a train driver would type in
the train number and the train searches in a given in a timetable where to
go next.

Kind regards,
Joachim

Tuomas Tiihonen wrote:
>
> Joachim Rubröder wrote:
>>
>> Hi Tuomas,
>>
>>> Our Next departure is used by the driver of the train. So after driver
>>> finishes one departure the driver can choose next departure for the train
>>> he/she is currently driving. If I understand correctly it is perhaps the
>>> vehicle->block closer to this.
>>
>> now we're getting closer. If the train driver chooses the next departure
>> its probably kind of a service plan for train drivers. This is not yet
>> implemented in railML but very similar to the rostering structure, wich is
>> a service plan for vehicles. The problem with the train drivers is that
>> they are much more complex (different skills, payment, pause times, ...)
>> to deal with.
>>
>
> Hi Joachim,
>
> actually the next departure is not related to the driver in our system.
> Driver is just the user who selects the next departure from the system. So
> in this context there is no need to know any information about the driver,
> or even who is the driver or even if there is the driver :)
>
> As driver is the user of the information he/she needs to know the next
> departures for the train he/she is sitting in not for driver itself.
>
> You can imagine that the train intelligently answers driver's question:
> "Dear train, please tell me all possible next departures where you, train,
> can depart from this exact station we are currently at"
>
> After this question train would generate this information, hopefully from
> railml by searching next departures from last driven departure. Or in
> railml next block from last driven block?
>
> Br,
> Tuomas
>



--
----== posted via PHP Headliner ==----

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: These: Das Aufteilen eines großen RailML-Netzes auf mehrere kleinere RailML-Netze darf zu keinem Verlust an Informationen führen.
Next Topic: timetable.trainParts.trainPart.ocpsTT.ocpTT.times scope value
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri May 17 03:42:49 CEST 2024