Home » railML newsgroups » railml.timetable » Haltezwecke / Stop descriptions
Re: Haltezwecke / Stop descriptions [message #1574 is a reply to message #1546] Thu, 18 May 2017 12:28 Go to previous messageGo to previous message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Dear Philip, Mico and all "lurkers",

I can possibly clarify some issues raised by Philip. This concerns the
current situation in railML, their current usage and the background
behind former development; I do want to value the current situation as
being sufficient or not.

> 2. there are some ambiguities with regard to the attributes
> - an activity might be 'ordered' by the RU for a commercial stop

To explain the intention behind the current situation: The term
"ordered" in the attribute /operationalStopOrdered/ refers to the
contractual relationship between IM and TOC.

The term "commercial" of the attribute of the same title in railML
traditionally refers to the contractual relationship between TOC and
end-customer, not to the contractual relationship between IM and TOC.

> - onOff is not clearly defined to be relevant to customers/goods only

May be "not clearly defined", but the intention behind is of course:
Only for commercial stops. Does not make sense for traditional
operational stops (which are not ordered). Theoretical, having an
operational stop for crew change, one could differ between on/off/both
but so far, there was never a practical demand for that and it is very
far-fetched just to raise or reduce the number of crew-members and fix
this in a timetable.

The intention behind onOff was clearly: Passenger information.

I want to add concerning stopOnRequest: Intended for passenger usage
only; makes no sense for "goods only" activities. The real background is
to tell the passenger whether he has to signal his wish for a stop
immediately before. For freight, a customer cannot signal a wish to stop
"immediately before" (by hand or button). At least, he would have to
phone or communicate in a more specialised way a special time period before.

From an operational view (concerning relationship between TOC and IM
and inside TOC and IM), "goods only" activities are always "on request",
so by default they can be omitted if there is no demand. The former
"Bedarfszug" has been made obsolete therefore.

> 3. in general I suspect that more than one 'activity' can be
> supplied for a stop - how shall 'conflicting' attributes be
> treated in such a case?

Concerning this, it is documented:
"It is not intended to write different stop types at the same station.
Concerning the usualities of railway operation: If there are reasons for
both a traffic stop and an operational stop, a traffic stop shall be
declared. If an operational stop becomes necessary by IM as well as by
TOC, it will be declared as an operational stop by TOC (ordered
operational stop)."

I agree that if we will define an enumeration of additional stop
informations (activities), this should be repeatable (several activities
at one stop).

Best regards,
Dirk.
 
Read Message
Read Message
Read Message
Read Message
Read Message
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: Timetable data elements for railVIVID
Next Topic: addendum to <stopDescription> in railML2.4
Goto Forum:
  


Current Time: Fri Mar 29 02:28:21 CET 2024