Home » railML newsgroups » railml.timetable » RFE for stop description
Re: RFE for stop description [message #762 is a reply to message #755] Wed, 21 March 2012 12:31 Go to previous messageGo to previous message
Joachim Rubröder railML is currently offline  Joachim Rubröder railML
Messages: 0
Registered: November 2019
Hi,
in a small group of power users we discussed this topic and identificated
two missing boolean attributes for stopDescription. These two could be
added for a new version 2.2 later this year.

* "guaranteedPass" for heavy freight trains, not allowed to be stopped
* "requestedByInfrastructure" for a stop, demanded by the infrastructure
manager

Is the wording OK? Will this be helpful and sufficient for now?

Best regards,

Joachim

Carsten Weber wrote:
>
> Hello,
>
> I just would like to start a theme to discuss this topic ...
>
> "Susanne Wunsch" <coord(at)commonrailmlorg> schrieb im Newsbeitrag
> news:bb2r519n59dfsf(at)remiheepsaxde...
>> Hello railML community,
>>
>> During our last meeting in Karlsruhe there raised some "requests for
>> enhancements" around the 'stopDescription' element. I add some personal
>> questions regarding its attributes.
>>
>> After the discussion, we may copy the conclusions to the appropriate
>> wiki page. :-)
>>
>> commercial="true"
>>
>> a stop, where passengers/goods may leave or get on the train,
>> depending on the 'onOff' attribute
>>
>> onOff="on"
>>
>> passengers/goods may only get on the train, leaving isn't allowed
>>
>> onOff="off"
>>
>> passengers/goods may only leave the train, getting on isn't allowed
>>
>> onOff="both"
>>
>> passengers/goods may leave or get on the train
>>
> Well, I think we can keep this option away. It is the same as if this
> attribute does not exist. So it is a special option to say "boarding only"
> or "leaving only".
>
>> stopOnRequest="true"
>>
>> the train stops only if passengers/goods from outside/inside the
>> train request for it
>>
>> stopOnRequest="false"
>>
>> the train stops in any case irrespective if there are
>> passengers/goods to get in or leave
>>
> I think this is the same. False is also meant if this attribute does not
> exist at the current ocpTT.
>
>> purpose="?"
>>
>> this attribute doesn't make any sense in case of a "commercial stop"
>>
>> commercial="false"
>>
>> a stop, where passengers/goods aren't allowed to leave or get on the
>> train, it is served for any operational purposes
>>
>> onOff="?"
>>
>> The 'onOff' attribute doesn't provide the value "none"!
>>
> You are right. But does it make sense to say anything about onOff in case of
> an operationalStop?
> The value "none" would only be required if you have to give an information
> about onOff but it is optional so you do not need this value.
> So what would you say: staff is only allowed to board the train? Customs are
> only allowed to leave the train?
> So I would say: In case of commercial="false" the attribute "onOff" can be
> ignored.
>
>> purpose="any description"
>>
>> this free text gives some explanation for the operational stop
>> reason
>>
>> There may be different independent reasons for some operational
>> stop. The 'purpose' attribute is no good choice for declaring them, it
>> is more useful for extra descriptions. These purposes may be concluded
>> in an extensible pre-defined enumeration list:
>>
>> * route conflict
>> * staff exchange
>> * goods handling without exchanging
>> * border facilities
>> * costums
>> * ...
>>
> Maybe shunting as a summary of changing locomotive, add or takeing vehicles
> away, joining or splitting, ...
>
>> Additional it would be helpful to define the organization in charge
>> for the purpose:
>>
>> * Infrastructure Manager (IM)
>> * Railway Undertaking (RU)
>> * Railway Company
>> * ...
>>
> Well this will be quite difficult. Do we need also an entry for "customs" or
> is it a problem of the Railway Undertaking?
> Whose fault is it do a change of train direction? Is it because of a missing
> track to avoid this stop or is it because of the train operator to change
> the row of waggons?
>
>> How about a commercial stop that is also used for some operational
>> reasons?
>>
> Well the combination of both informations is not prohibited. So you can also
> say commercial="true" and purpose "staffExchange" why not?
>
> The more difficult question is: What about an operational stop with several
> purposes? For example "staffExchange" and "customs"?
>
> The most important question is: How do we need to handle this stop in case
> of an operational stop?
> So if the purpose is set to "routeConflict" and at the current day the
> conflict partner does not exist (e. g. because of a delay) this stop can be
> taken away by the infrastructure company without any further information. So
> it means "green" at the signal instead of (an expected) red.
> Or if the train operation company says: we do not need to do a staff
> exchange today the stop can also be taken away. Therefore it would be
> helpful to inform the infrastructure operator to set the signal to "green"
> to keep the train on runing (if possible).
>
> In this case it might also be helpful to be able to define a flag like
> "quarantedPass" in case of a heavy train which can not restart at this ocpTT
> if it has to stop there. This will be a little bit in opposition to the
> headline "STOPdescription" but I think this is not really tragic.
>
>> What do you think about it?
>>
> I hope I have written enough above. :)
>
>> Any comments, hints, questions are welcome. :-)
>
> Best regards.
>
> Carsten
>
>
>
>



--
----== posted via PHP Headliner ==----
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Difference between 'load' and 'timetableLoad'
Next Topic: <trackRef>.dir
Goto Forum:
  


Current Time: Wed May 15 17:33:00 CEST 2024