Home » railML newsgroups » railML.infrastructure » speed profiles for general directions
speed profiles for general directions [message #304] Thu, 26 April 2012 20:46 Go to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
Hello Susanne and all others,

> [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>.
Dirk.
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 next 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
Re: speed profiles for general directions [message #515 is a reply to message #367] Mon, 11 March 2013 14:03 Go to previous message
Susanne Wunsch railML is currently offline  Susanne Wunsch railML
Messages: 0
Registered: January 2020
Dear railML users,

At the railML conference in Berlin, another term ("path") was proposed
for the child element "route". The renaming may be done in a short-term,
if we get some fast feedback. (Look at the bottom of this thread.)

Christian Rahmig <coord(at)infrastructurerailmlorg> writes:
> 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

Nobody up to now responded to this proposal and implementation!

I summarized the renaming idea in Trac ticket #226. [2]

During the last railML conference (2013-03-06) in Berlin the term
route in a speed profile was questioned.

This child element is for indicating special speed profiles between
different neighbouring ocps no matter that the train uses one and the
same infrastructure (e.g. tracks, switches). (see also #41 for
implementation purposes)

Another term may be "path" that clearly distances from the
IXL-specific "route".

* A "path" is more seen as a runway.
* A "route" is more seen as a secured runway.

From "GLOSSARY OF RAILROAD OPERATION AND CONTROL" (1):

ROUTE
A path through an interlocking, along which an authorized movement
is to be made.

(1) http://www.joernpachl.de/glossary.htm

Any comments* appreciated.

Kind regards...
Susanne

[2] https://trac.assembla.com/railML/ticket/226
* +1, -1, hints, questions...

--
Susanne Wunsch
Schema Coordinator: railML.common
Previous Topic: Balise / baliseGroups : structure & attributes
Next Topic: Shown values on mileposts
Goto Forum:
  


Current Time: Mon Jul 15 09:57:18 CEST 2024