Home » railML newsgroups » railML.infrastructure » More detailed 'speed change' definitions
Re: More detailed 'speed change' definitions [message #301 is a reply to message #280] Tue, 24 April 2012 23:31 Go to previous messageGo to previous message
Susanne Wunsch railML is currently offline  Susanne Wunsch railML
Messages: 0
Registered: January 2020
Hello to all who are interested,

We discussed some open issues of the upcoming speed change / speed
profile enhancements (for railML version 2.2) afterwards the todays'
railML meeting in Dresden. I conclude the outcomes herein.

[directions in speed changes]

<speedChange> elements offer the "dir" attribute with the enumeration
values "up" and "down".

(See also Trac ticket #145 [1] for renaming the enumeration values with
next major release.)

The current enumeration value "both" is marked deprecated for more
clear semantics.

[position of speed changes in the XML tree]

<speedChange> elements stay where they are currently defined.

<speedProfile> elements are seperated from the <tracks> and (with
respect to its container element <speedProfiles>) a direct
child of the <infrastructure> element.

[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?

[train relation]

What is a real use case for the enumeration value "midOfTrain"? Are
there any speed aspects that are valid since half of the train passed
its defined position?

If it is not the case, we would suggest not to define it.

[minimum percentage of brake power]

At some railway infrastructure companies the minimum percentage of
brake power can't be directly calculated by means of physics. It is
somehow defined by some legal body.

Therefore we would suggest an additional attribute
"minimumBrakePercentage" for this value in the <speedProfile> element.

Any comments, remarks, questions are highly appreciated.

[1] http://trac.assembla.com/railML/ticket/145

--
Kind regards...
Susanne
 
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 14:01:22 CET 2024