Home » railML newsgroups » railml.timetable » RFE for stop description
RFE for stop description [message #754] Tue, 15 November 2011 09:45 Go to next message
Susanne Wunsch railML is currently offline  Susanne Wunsch railML
Messages: 0
Registered: January 2020
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

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

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"!

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
* ...

Additional it would be helpful to define the organization in charge
for the purpose:

* Infrastructure Manager (IM)
* Railway Undertaking (RU)
* Railway Company
* ...

How about a commercial stop that is also used for some operational
reasons?

What do you think about it?

Any comments, hints, questions are welcome. :-)

Kind regards...
Susanne

--
Susanne Wunsch
Schema Coordinator: railML.common
Re: RFE for stop description [message #755 is a reply to message #754] Tue, 15 November 2011 14:59 Go to previous messageGo to next message
Carsten Weber is currently offline  Carsten Weber
Messages: 27
Registered: November 2011
Junior Member
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
Re: RFE for stop description [message #762 is a reply to message #755] Wed, 21 March 2012 12:31 Go to previous messageGo to next 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 ==----
Re: RFE for stop description [message #767 is a reply to message #762] Mon, 26 March 2012 19:19 Go to previous messageGo to next message
Dirk Bräuer is currently offline  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/
Re: RFE for stop description [message #788 is a reply to message #767] Tue, 29 May 2012 16:57 Go to previous messageGo to next message
Joachim Rubröder railML is currently offline  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 ==----
Re: RFE for stop description [message #797 is a reply to message #788] Wed, 30 May 2012 15:15 Go to previous message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Danke, Joachim, auch für das Anpassen im Wiki. Dirk.
Previous Topic: Difference between 'load' and 'timetableLoad'
Next Topic: <trackRef>.dir
Goto Forum:
  


Current Time: Fri Mar 29 12:06:50 CET 2024