Home » railML newsgroups » railML.infrastructure » Speed Panels: types and reference to <speedChange>
Re: Panels in general [message #509 is a reply to message #487] Sat, 12 January 2013 18:10 Go to previous messageGo to previous message
Christian Rahmig is currently offline  Christian Rahmig
Messages: 151
Registered: January 2011
Senior Member
Dear Dirk and other railML users,

Am 03.12.2012 16:17, schrieb Dirk Bräuer:
> Dear Susanne and Christian,
>
>> - A <speed> signal information further contains the parameters
>> "kind" (values: announcement, execution and end) and "speedChangeRef".
>
> A list of <speedChangeRefs> please. (Several speed profiles, each
> referencing the same <speedChange>.)

+1

> I suggest not to distinguish between "execution" and "end" because of
> this may depend on the speed profile. Rather, an attribute
> /kind/="announcement"|"execution" should be enough also for the "ends".

+1

> Additionally, we need both the "valid for head of train" (not the same
> as /kind/!) and "virtual" information as well, as already discussed and
> agreed.

The attribute @virtual already exists for the <signal> element and does
not have to be declared again in the sub-element. For the information
about the point of validity of the signal/panel, I added the attribute
@trainRelation to the signal's sub-element <speed>. Probably, it is even
useful to implement the attribute @trainRelation in the <signal> element
as it might be of interest for other types of signals as well.

>> - A <milepost> signal information further contains the parameters
>> "shownValue" and "realValue".
>
> Is "realValue" the same as the /pos/ of this element at the track, isn't
> it?

You are right. It is sufficient to only declare the attribute @shownValue.

>> - A <braking> signal information further contains the parameter
>> "trackConditionRef", which refers to a <trackCondition> where the
>> attribute "type" allows for the values 'nonStoppingSection',
>> 'noRegenerativeBraking', 'noEddyCurrentBraking', 'noMagneticShoeBraking'.
>
> I suggest to use a bake type already existing (tVehicleBrakes or such)
> and an attribute declaring "not for vehicles with the following brakes...".

Since we are only referencing to a <trackCondition> element, this would
mean to change the attributes of the <trackCondition>.

> Please do already think at the German places for "Betriebsbremsung" or
> "Zwangshalt" - should we use such a <signal> there, possibly with
> /virtual/='true'? If so, we would also use a /type/ therefore.

Don't we have implemented the <speedChange> attributes @mandatoryStop
and @mandatoryBraking for that? Consequently, we need to add a reference
from a braking signal to a <speedChange> element as we defined it for
all speed signals.

> Best regards,
> Dirk.

Thank you for your comments! I considered them in the Trac ticket [1] as
well.

[1] https://trac.assembla.com/railML/ticket/173

Regards

--
Christian Rahmig
railML.infrastructure coordinator
 
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: new attributes on the ocp element
Next Topic: railML 3 infrastructure model
Goto Forum:
  


Current Time: Mon May 06 14:08:22 CEST 2024