| speed profiles for general directions [message #304] |
Thu, 26 April 2012 20:46  |
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 #515 is a reply to message #367] |
Mon, 11 March 2013 14:03  |
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
|
|
|
|
Members
Search
Help
Login
Home
