Home » railML newsgroups » railML.infrastructure » More detailed 'speed change' definitions
Re: Obligational stop [message #525 is a reply to message #524] Fri, 15 March 2013 15:38 Go to previous messageGo to previous message
thomas.kauer is currently offline  thomas.kauer
Messages: 15
Registered: January 2004
Junior Member
Dirk Bräuer wrote:
>
> Dear Susanne,
>
> Am 12.03.2013, 22:57 Uhr, schrieb Susanne Wunsch <coord(at)commonrailmlorg>:
>> We want to remove both attributes (mandatoryStop and mandatoryBraking)
>> from the "speedChange" element for the upcoming 2.2 version.
>
> Ah, I understand.
>
>> And indeed both scenarios
>> are some kind of operational-rule-driven.
>
> The "Betriebsbremsung" more than the "mandatory stop".
>
> So I agree to remove "Betriebsbremsung" to somewhere else, may be away
> from <infrastructure> to <rules> or such.
>
> I do not agree concerning "mandatory stops". Their reason is clearly
> infrastructure. In the case of level crossings (the case you always quote)
> the reason is "bad sight" from street to railway line due to an obstacle
> in the triangle between a car, a train, and the level crossing. This
> "obstacle" - possibly a house - is clearly infrastructure - somebody has
> built it there. May be it's not railway property, but rather
> infrastructure in general than rule.
>
> Other examples for "mandatory stops" are at least the same
> "infrastructure-like": RETB stop markers are a kind of starter signal, or
> H-Tafel or Trapeztafel in Germany.
>
> Of course all these also have a touch of rule: The reason for a starter
> signal is a rule (just one train in one section). Despite this, I guess
> you would treat starter signals, H-Tafel, and Trapeztafel as
> infrastructure, too. So you should do the same with mandatory stop marker
> boards.
>
> Another example would be Ra10 / Rangierhalttafel from Germany (limit of
> shunting marker board in English). Is it infrastructure or rule? Some of
> both, of course. There is no physical need to stop there, as there is no
> physical need to stop at any other main signal or marker board.
>
> However, following the rule Christian once said: At least if you can touch
> it, it is infrastructure. You can touch a main signal, a Ra10, as well as
> a "mandatory stop" marker or these "0 km/h" speed signals at German level
> crossings with "bad sight".
>
> Convinced?
>
>> The "mandatoryBraking" attribute, which is the topic of this thread, may
>> be modelled as an operational stop with a reference to its level
>> crossing. But this idea is also not fully checked and far from "ready to
>> implement".
>
> I guess there is a mistake in your writing: You do not mean
> "mandatoryBraking" but "mandatoryStop".
>
> The "mandatoryStop" has another character than an operational stop.
> Operational stops are by far not mandatory - on the contrary. They can be
> skipped (the train is allowed to run through) under certain conditions,
> which are pure of "timetabling" matter.
>
> Currently, you cannot create an operational stop in RailML referencing a
> level crossing - stops can only reference OCPs, and a level crossing is no
> OCP. It would be necessary to additionally create an OCP at the place of
> the level crossing to model the operational stop.
>
> Anyway, with this technology you cannot express that stops are regularly
> necessary forced by the infrastructure manager (or some other authority)
> at this place. I think it should be possible to create infrastructure-only
> RaiLML file (a RailML file with just infrastructure, no trains). If this
> is given to anybody who wants to create a timetable, it should tell him as
> much as he could see "in nature". It should spare him to go outside and
> look at each sign. If you agree with this, the "mandatory braking" marker
> boards should be infrastructure.
>
> If you do not want to put them as an attribute of <speedChange>, then
> please allow a cross-reference from/to <speedChange> to keep background
> information.
>
> Best regards,
> Dirk.
>
>
Dear Dirk

I agree that if there is a "mandatory braking marker" this should be part
of the infrastructure. So it should be treated as a marker (a kind of
signal). A lot of speed changes have their origins in a amrker or some
other kind of signal - a cross-reference would very well fit for that need.
If the "mandatory braking" has no marker but is only written somewhere in
operational rules you would have to make a difference between "general"
rules for all trains and "timetable specific" rules that may only be
applied by some railway companies running there.
But I don't think you need a <speedChange> for a "mandatory braking
marker" since the resulting speed is depending on the exact breaking rules
and train properties, so you normally won't be able to give any conrete
speeds at so a <speedChance>.

Best regards,
Thomas


--
----== posted via PHP Headliner ==----
 
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 10:57:58 CET 2024