Home » railML newsgroups » railML.infrastructure » speed profiles for general directions
Re: speed profiles for general directions [message #367 is a reply to message #304] Sat, 22 September 2012 10:09 Go to previous messageGo to previous message
Christian Rahmig is currently offline  Christian Rahmig
Messages: 151
Registered: January 2011
Senior Member
Dear railML users,

>> [different run history]
>>
>> The actual speed aspect depends not only on the rollingstock
>> characteristics as mentioned in the previous postings. It sometimes
>> depends on the route through a "branching station" from a macroscopic
>> point of view.
>>
>> Given the route between the neighbouring stops/stations (ocps) the
>> different speed aspects at the same track for the same rollingstock
>> characteristics may be defined.
>>
>> So far we would need two attributes for refering to <ocp id="">
>> elements at the <speedProfile> element. "from" and "to" don't help in
>> this case because they also apply to the other running direction which
>> would be confusing.
>>
>> How about the attributes "ocpRef1" and "ocpRef2"? Or "neighbour1" and
>> "neighbour2"? Or "neighbourOcpRef1" and "neighbourOcpRef2"?
>>
>> Any other (even better) naming suggestions?
>
> How about a kind of sub-structure:
>
> <speedProfile>
> ...
> <AppliesForRoute>
> ocpRef=
> ocpRef=
> ...
> </AppliesForRoute>
> </speedProfile>
>
> The <AppliesForRoute> is a container for as much ocpRef's as necessary,
> at least two. (So far, I can't imagine that it depends on more than two
> ocp's but anyway, we were not sure about this when we had that discussion.)
>
> The order of the several ocpRef's doesn't matter. A train has to pass
> all of them for the speed profile to apply.
>
> We could shorten the element name simply to <route>.

In accordance with trac ticket [1] a new element <route> has been
defined within the element <speedProfile> for the upcoming railML 2.2.
It indicates a train run between two neighboring OCPs independent from
the direction. The <route> element acts as a simple container for a
number of <ocpRef> elements:

<speedProfile ...>
...
<route>
<ocpRef ref="ocp1">
<ocpRef ref="ocp2">
...
</route>
</speedProfile>

This <route> element must not be seen from an "interlocking view" as it
does not represent a "classical" route / running-track from a starting
signal and a destination point.

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

Regards

--
Christian Rahmig
railML.infrastructure coordinator

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Previous Topic: Balise / baliseGroups : structure & attributes
Next Topic: Shown values on mileposts
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Mon Jul 22 22:14:55 CEST 2024