| Re: Steckenunterbruch/line blocking [message #910 is a reply to message #909] |
Wed, 05 December 2012 11:24  |
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
|
|
|
|
Members
Search
Help
Login
Home
