Home » railML newsgroups » railml.timetable » RFE for stop description
| Re: RFE for stop description [message #788 is a reply to message #767] |
Tue, 29 May 2012 16:57   |
Joachim Rubröder railML
Messages: 0
Registered: November 2019
|
|
|
|
Hi,
I've added the two new attributes and closed the tickets #140 and #143:
* "guaranteedPass" for heavy freight trains, not allowed to be stopped
* "operationalStopOrdered" for a stop, demanded by the infrastructure
manager
Best regards,
Joachim
Dirk Bräuer wrote:
>
> Dear Joachim,
>
>> * "guaranteedPass" for heavy freight trains, not allowed to be stopped
>
> No objection from my side.
>
>> * "requestedByInfrastructure" for a stop, demanded by the infrastructure
>> manager
>
> Something has coincided here. (A crossing - but unfortunately Internet
> seams to be double-track...)
>
> I have seen that you already have created 'requestedByInfrastructure'.
> During the same time, I have prepared the examples with
> 'operationalStopOrdered'. I had the opinion that on Monday 19th we have
> agreed to 'operationalStopOrdered' but I am not sure anymore.
>
> Anyway, either I change the examples or you change the Wiki. I think both
> is simply possible and nobody of both of us has a problem with it. So what
> to do?
>
> I have a very small preference on 'operationalStopOrdered' because of that:
> With an operational stop, we mean mainly "stopping because of a crossing
> (only)" (oncoming train at single track) or "because of an overtaking" or
> simply "because of an occupied track". But if it would be called
> 'requestedByInfrastructure' one could argue: "This stop is not requested
> by infrastructure but by the oncoming train. The oncoming train is no
> infrastructure." This would leave operational stops only to
> 'Spitzkehren'... which we do not mean. Therefore, I would rather "turn the
> boolean around" and call it 'operationalStopOrdered'. I am aware that not
> all countries have the system of 'ordering' trains in the meaning of
> liberalism, but 'ordered' needs not to be translated with 'bestellt' but
> can also be translated with 'angewiesen', which will also be understood e.
> g. in Northern America, I think.
>
> Any objections?
>
> Best regards,
> Dirk.
>
>
> ---
> Am 21.03.2012, 12:31 Uhr, schrieb Joachim Rubröder
> <coord(at)timetablerailmlorg>:
>
>> 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 ==----
|
|
|
|
Current Time: Thu May 16 02:40:00 CEST 2024
|
Members
Search
Help
Login
Home
