| Re: Proposal: New optional attibutes on type block [message #943 is a reply to message #941] |
Fri, 19 July 2013 17:32   |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear Mr. Naujoks and all others,
first, to avoid misunderstandings also for other readers: I guess this is
about circulations! ("Physical location where a block begins and ends" may
also sound like "block" in the meaning of "tokenless train operation"
along a section of track.)
> In the overview mode we are delivering only blocks without containing
> details (i.e. block parts).
Actually, there is such a possibility to have <blocks> in a circulation
which have no actual train/trainPart in the current RailML file. But this
possibility is "one level up": At <blockParts>, not at <blocks>.
Your can read it in the example explanation e. g. at [1] (which is linked
e. g. from [2]):
> Fahrt ohne Referenz auf einen Zugteil: mission=fullRun oder emptyRun;
> trainPartRef darf nicht angegeben sein, startOcpRef, endOcpRef, begin
> und end müssen angegeben sein.
> Dienst (der keine Fahrt ist): mission =shunting (Rangierdiensten),
> =maintenance (Wartungsdiensten), =standBy (Bereitschafts- und
> Reservedienste), =preheating (Vorheizdiensten), =refuel (Auffüllen von
> Vorräten, Tanken usw.); trainPartRef darf nicht angegeben sein,
> startOcpRef, endOcpRef, begin und end müssen angegeben sein,
> startOcpRef=endOcpRef.
Run w/o reference to a train part: mission=fullRun or emptyRun;
trainPartRef must not be set, startOcpRef, endOcpRef, begin and end have
to be set.
Duty which is no actual run: mission = shunting, maintenance, standBy,
preheating, refuel; trainPartRef must not be set, startOcpRef, endOcpRef,
begin and end have to be set, startOcpRef=endOcpRef.
So the solution is: Create a simple place-holder <blockParts> for the
desired <block> and then create a <block> referring this place-holder
<blockPart>.
(I'm aware that this may be easier written than done. It is not meant
cynically. But is there a real need to create a second solution where
already one exists or did I misunderstood the situation?)
With best regards,
Dirk Bräuer.
[1[ www.irfp.de/download/railml_beispiel_umlauf.pdf
[2] www.wiki.railml.org/index.php?title=TT:block
---
Am 30.04.2013, 14:43 Uhr, schrieb Horst Naujoks <horstnaujoks(at)qnamiccom>:
> Hi all,
>
> I'like to propose the following enhancement for an upcoming railML
> release
> (not necessarily 2.2):
>
> The physical location where a block begins and ends could be implicitly
> determined by inspecting its
> contained blockpart sequences and block parts respectively. From first
> found block part the attribute
> startOcpRef could be used and analogous from the last one the endOcpRef
> attribute.
> But this approach requires that all the block parts are present.
> We are using railML in a scenario, where present blocks in two different
> modes: overview or details.
> In the overview mode we are delivering only blocks without containing
> details (i.e. block parts).
> Nevertheless, we want to provided the above mentioned information about
> where a block start and
> ends. Today, we are using two custom attributes for that, but we are sure
> that it would be even
> helpful for the standard railML to have to new, optional attributes
> startOcpRef and analogous from
> endOcpRef on the type block. Of course, these attributes where redundant
> in case of present block
> parts.
>
> Kind Regards,
>
> Horst Naujoks
|
|
|
|
Members
Search
Help
Login
Home
