Re: Steckenunterbruch/line blocking [message #909] |
Mon, 03 December 2012 20:56 ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
Dirk Bräuer
Messages: 311 Registered: August 2008
|
Senior Member |
|
|
Dear Joachim and all others,
concerning the suggestion of line blockings in RailML (previous mentioned
at <infrastructure> by Renato Kluser), here comes my suggestion for a
RailML structure:
First, the easy things:
<trackBlockings>
<trackBlocking id=... name=… description=… remarks=… />
- further properties see below -
</trackBlocking>
</trackBlockings>
Now to the real properties. These could be simple attributes of
<trackBlocking> from my side but could also be sub-elements. Sub-elements
may be preferred to declare constraints but from my side, the constraints
are not too much difficult so Wiki should be enough for them.
<trackRefs>, trackRef=…
- reference to one or more <track>.id
- at least one must be given
- more than one is typical for a blocking of all tracks of a
multiple-track line (“line blocking” was original intended)
fromOcpRef=…, toOcpRef=…
- compulsory attributes
- references to <ocp>.id
validity Period: should be a “choice” of exactly one of the following two
options:
a) <repeating operatingPeriodRef=… startTime|startAfterTrainRef =…
endTime|untilBeforeTrainRef=… />
- operatingPeriodRef is compulsory
- startTime/startAfterTrainRef and endTime/ untilBeforeTrainRef are to be
used “disjunctive”
- startAfterTrainRef/untilBeforeTrainRef are references to <train>.id
- The blocking is to be repeated at each of the days of the
<operatingPeriod> from start time to end time or trains. The trains must
operate at the given days.
b) <non-stop startDate= endDate= startTime|startAfterTrainRef =…
endTime|untilBeforeTrainRef=… />
- startDate and endDate are compulsory
- startTime/startAfterTrainRef and endTime/ untilBeforeTrainRef are to be
used “disjunctive”
- startAfterTrainRef/untilBeforeTrainRef are references to <train>.id
- The blocking happens one time non-stop throughout from
startDate+startTime/train until endDate+endTime/train. The trains must
operate at the given days.
---
Example for a repeating one: Regular bridge opening times of a swing bridge
<trackBlockings>
<trackBlocking id=... name='Afternoon-opening' description='Summer-only
afternoon opening for sailing ships with high masts' remarks='Added by
Dirk as an example' fromOcpRef='ocp_WSRR' toOcpRef='ocp_WAF' />
<trackRef ref='track_80.6311.1' />
<repeating operatingPeriodRef='opp_Summer' startTime='16:30'
endTime='17:15' />
</trackBlocking>
</trackBlockings>
---
Example for a non-stop one: Maintenance works
<trackBlockings>
<trackBlocking id=... name='Maintenance works' description='Ballasting
with Plasser & Theurer' remarks='Please provide a replacement bus'
fromOcpRef='ocp_Br' toOcpRef='ocp_Vi' />
<trackRef ref='track_85.140.1' />
<trackRef ref='track_85.140.2' />
<non-stop startDate='2012-07-15' endDate='2012-07-29'
startAfterTrainRef='tr_R567' endTime='04:00' />
</trackBlocking>
</trackBlockings>
---
Best regards,
Dirk.
----
Am 03.12.2012, 17:25 Uhr, schrieb Kluser Renato <renatokluser(at)mgbahnch>:
> ENGLISH SUMMARY: The MGB railway uses railML 2.0
> for data exchange from our timetabling system to
> our disposition system. Currently we need an
> extension of the standard to transfer line
> blockings from one system to another.
>
> Hallo railML-Partner,
>
> wir, die Matterhorn Gotthard Bahn (MGB),
> betreiben ein 144 km langes Meterspurnetz im
> Süden der Schweiz. Zum Datenaustausch zwischen
> unserem Fahrplansystem FBS und dem
> Kundeninformations- und Dispositionssystem KIS nutzen wir railML 2.0.
>
> Nun möchten wir auch noch die in FBS verwalteten
> Streckenunterbrüche an das Dispositionssystem
> übergeben und schlagen daher eine Erweiterung des
> railML-Standards vor. Die Abbildung folgende
> Arten von Unterbrüchen wäre für uns unerlässlich:
>
> - Strecke von Betriebsstelle BRMG (Brig) bis Visp
> (VISP) gesperrt vom 15. Juli 2012 22.00 Uhr bis
> 29. Juli 2012 4.00 Uhr; Grund: Bauarbeiten am Gleis
> - Strecke von Oberwald (OBW) bis Realp (REAL)
> gesperrt im Zeitraum vom 3. Oktober 2012 bis 16.
> Oktober 2012; jeweils zwischen 22.45 Uhr bis 3.45
> Uhr am Folgetag; Grund: Fahrleitungsrevision
> - Strecke 140 von km 22,790 bis 26,186 gesperrt
> bis 3. Dezember 2012; 16.00 Uhr
>
> Eine Erweiterung der Eigenschaften eines
> Unterbruchs (z.B. 'nur für elektrische
> Fahrzeuge', 'nur für Fahrzeuge des Typs ...'
> usw.) und zusätzliche Informationen wie Busersatz
> usw. wäre denkbar, ist aber für uns nicht dringlich.
>
> Beste Grüsse,
>
> Renato Kluser
> Betrieb
> Verkehrsplanung und Sicherheit
>
> Matterhorn Gotthard Bahn
> Bahnhofplatz 7
> CH-3900 Brig
> http://www.mgbahn.ch
>
|
|
|
Re: Steckenunterbruch/line blocking [message #910 is a reply to message #909] |
Wed, 05 December 2012 11:24 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) |
Christian Rahmig
Messages: 151 Registered: January 2011
|
Senior Member |
|
|
Dear Dirk,
Am 03.12.2012 21:13, schrieb Dirk Bräuer:
> please follow me to:
>
> [1]
> http://www.railml.org/forum/ro/index.php?group=2&offset= 0&thread=93&id=350
for getting a connection to another forum, it is better to use the
followup-tag. However, I still think, that we are talking about an
infrastructure aspect and I hope the next lines can clarify my opinion:
> First, the easy things:
>
> <trackBlockings>
> <trackBlocking id=... name=… description=… remarks=… />
> - further properties see below -
> </trackBlocking>
> </trackBlockings>
Your idea limits the blocking to tracks, which is quite a static
approach and, furthermore, need to be extended very soon. Despite a
certain track, also a signal or a balise or a switch etc. can be
disabled in the sense of "is not available for operation". Therefore, I
suggest to define the "disabled" feature as a child elment for all the
relevant infrastructure objects, e.g. tracks, switches, signals.
> Now to the real properties. These could be simple attributes of
> <trackBlocking> from my side but could also be sub-elements.
> Sub-elements may be preferred to declare constraints but from my side,
> the constraints are not too much difficult so Wiki should be enough for
> them.
>
> <trackRefs>, trackRef=…
> - reference to one or more <track>.id
> - at least one must be given
> - more than one is typical for a blocking of all tracks of a
> multiple-track line (“line blocking” was original intended)
>
> fromOcpRef=…, toOcpRef=…
> - compulsory attributes
> - references to <ocp>.id
Again, the attributes that you propose here, are only valid for track
blockings. We may think about allowing for definition of points on
tracks, from where on the track is blocked. However, since the
"disabled" sub-element will be available for all relevant tracks, there
is no need to define a length of the blocking section in form of a
"from-to" attribute group.
> validity Period: should be a “choice” of exactly one of the following
> two options:
>
> a) <repeating operatingPeriodRef=… startTime|startAfterTrainRef =…
> endTime|untilBeforeTrainRef=… />
> - operatingPeriodRef is compulsory
> - startTime/startAfterTrainRef and endTime/ untilBeforeTrainRef are to
> be used “disjunctive”
> - startAfterTrainRef/untilBeforeTrainRef are references to <train>.id
> - The blocking is to be repeated at each of the days of the
> <operatingPeriod> from start time to end time or trains. The trains must
> operate at the given days.
>
> b) <non-stop startDate= endDate= startTime|startAfterTrainRef =…
> endTime|untilBeforeTrainRef=… />
> - startDate and endDate are compulsory
> - startTime/startAfterTrainRef and endTime/ untilBeforeTrainRef are to
> be used “disjunctive”
> - startAfterTrainRef/untilBeforeTrainRef are references to <train>.id
> - The blocking happens one time non-stop throughout from
> startDate+startTime/train until endDate+endTime/train. The trains must
> operate at the given days.
The definition of time periods during which the infrastructure is
disabled is not the task of the infrastructure schema. Here, I suggest
to just implement a reference from the <disabled> element to an
operating period.
Further comments appreciated...
Regards
--
Christian Rahmig
railML.infrastructure coordinator
|
|
|