Home » railML newsgroups » railML.infrastructure » More detailed 'speed change' definitions
Re: Obligational stop [message #516 is a reply to message #444] Mon, 11 March 2013 14:38 Go to previous messageGo to previous message
Susanne Wunsch railML is currently offline  Susanne Wunsch railML
Messages: 0
Registered: January 2020
Dear railML users,

During our railML conference in Berlin a discussion about the issue of
this thread started. (Look at the end of this posting.)

Susanne Wunsch <coord(at)commonrailmlorg> writes:
> Dirk Bräuer <dirkbraeuer(at)irfpde> writes:
>>> ** How to define an "obligational stop" where all or only certain
>>> trains have to stop prior going on with the same speed aspect as
>>> before?
>>> ** Could this be an attribute of the speedChange element?
>>
>> That is an issue I would like to see solved with RailML 2.2. I would
>> prefer either such an attribute (obligational stop of head/end of
>> train). The other, possible “cleaner” but also more complex solution
>> would be to define an infrastructure element “obligationalStop”
>> (independently from speed changes).
>>
>> I think the attribute at a speedChange will be ok.
>
> This issue is implemented with the following commit:
>
> http://trac.assembla.com/railML/changeset/456
>
> The following attributes are added to the 'speedChange' element.
>
> <xs:attribute name="mandatoryStop" type="xs:boolean">
> <xs:annotation>
> <xs:documentation>specifying the speedChange as a mandatory stop point, e.g. in front of a level crossing</xs:documentation>
> </xs:annotation>
> </xs:attribute>

I summarized the new arguments in the appropriate Trac ticket. [1]

During the last railML conference (2013-03-06) in Berlin the use case
for "mandatory stop" was questioned.

The described scenario is very specific to the German railway
operations. In order to avoid country-specific operation rules in the
context of the more general railML data exchange, the current
implementation should be removed.

As a short-term solution, the partners may use any-Attributes instead.

An implementation following the idea of an operational stop would be
preferred to the current implementation as a "speedChange".

Any comments* appreciated.

[1] http://trac.assembla.com/railML/ticket/100#comment:4
* +1, -1, hints, questions...

Kind regards...
Susanne

--
Susanne Wunsch
Schema Coordinator: railML.common
 
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
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: Re-factoring of <infraAttributes>
Next Topic: Hierarchy of overlaying speed profiles and National vs. Generic speed profiles.
Goto Forum:
  


Current Time: Fri Mar 29 13:36:31 CET 2024