Home » railML newsgroups » railml.timetable » Proposal: New optional attibutes on type block
Proposal: New optional attibutes on type block [message #941] Tue, 30 April 2013 14:43 Go to next message
horst.naujoks is currently offline  horst.naujoks
Messages: 5
Registered: December 2012
Junior Member
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

--
----== posted via PHP Headliner ==----
Re: Proposal: New optional attibutes on type block [message #943 is a reply to message #941] Fri, 19 July 2013 17:32 Go to previous messageGo to next message
Dirk Bräuer is currently offline  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
Re: Proposal: New optional attibutes on type block [message #945 is a reply to message #943] Mon, 16 September 2013 17:01 Go to previous message
horst.naujoks is currently offline  horst.naujoks
Messages: 5
Registered: December 2012
Junior Member
Dear Mr. Bräuer

First of all, thanks fro your reply.
Your are right, my input is about Blocks/BlockPart in the context of
circulations.

Your suggested solution for my request (using startOcpRef/endOcpRef on
'place-holder'
BlockParts) is feasible, but not matching my primarily intention.

My suggested new optional startOcpRef/endOcpRef attributes on the Block
element should
provide a convenient way to deliver useful information at the block level
even if its redundant to
some information a level below (BlockParts).
In fact, I wish to declare where a block starts, respectively ends,
completely without the use of
BlockParts.

Kind Regards,

Horst Naujoks

Dirk Bräuer wrote:
>
> 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
>
>


--
----== posted via PHP Headliner ==----
Previous Topic: train uniqueness constraint II
Next Topic: Different representations of a train
Goto Forum:
  


Current Time: Thu Mar 28 11:24:41 CET 2024