| Re: RFE for stop description [message #767 is a reply to message #762] |
Mon, 26 March 2012 19:19   |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
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
>>
>>
>>
>>
>
>
>
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
|
|
|
|
Members
Search
Help
Login
Home
