Home » railML newsgroups » railML.infrastructure » More detailed 'speed change' definitions
Re: More detailed 'speed change' definitions [message #311 is a reply to message #301] Sat, 16 June 2012 18:59 Go to previous messageGo to previous message
Christian Rahmig is currently offline  Christian Rahmig
Messages: 151
Registered: January 2011
Senior Member
Hello Susanne et.al.,

> 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.

agreed.

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

agreed.

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

c.f. ongoing discussion in thread "speed profiles for generl directions" [2]

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

c.f. ongoing discussion in thread "train relation" [1]

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

c.f. ongoing discussion in thread "speed profiles and braking
percentages" [3]

[1]
http://www.railml.org/forum/ro/index.php?group=1&offset= 0&thread=45&id=121

[2]
http://www.railml.org/forum/ro/index.php?group=1&offset= 0&thread=46&id=122

[3]
http://www.railml.org/forum/ro/index.php?group=1&offset= 0&thread=44&id=120

---
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
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: Thu Apr 18 15:12:20 CEST 2024