Home » railML newsgroups » railML.infrastructure » [railMl2] Proposal for new attribute @switchable in <baliseGroup> and wiki refinement
[railMl2] Proposal for new attribute @switchable in <baliseGroup> and wiki refinement [message #2673] Thu, 25 February 2021 10:30 Go to next message
Torben Brand is currently offline  Torben Brand
Messages: 156
Registered: March 2016
Senior Member
The Norwegian railways sector proposes to add an attribute @switchable to the element <baliseGroup> to describe that the balise group (or the first included balise) is switchable.

Further we suggest defining clearer in the wiki how individual balises should be modelled in a group:

You can model the balise/baliseGroup relation in three levels of detail:
• Only the baliseGroup: One dummy balise is placed (since baliseGroup cannot exist alone) using attributes @id, @dir and @pos
• baliseGroup with individual functional balises: All balises of baliseGroup are placed with identical locations (describing the location of the very first balise of the baliseGroup) using attributes @id, @name, @dir, @pos
• baliseGroup with individual balises with (real) locations

The enumeration of attribute <baliseGroup>@type shall be extended to cover specific (national) types of balises. (Attention: enumeration is already extendable)

A best practice example (or three ones) shall be added to the railML2 wiki pages of <balise> and <baliseGroup>.

What does the community think?
Re: [railMl2] Proposal for new attribute @switchable in <baliseGroup> and wiki refinement [message #2697 is a reply to message #2673] Fri, 09 April 2021 16:54 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Torben,

thank you very much for your valuable input. I filed a Trac ticket #431 [1] for the topic, where I integrated also your solution proposal.

Just one question (for the whole community): What should be "switchable": the <balise> or the <baliseGroup>?

For comparison: in railML 3.2 only the <balise> can be specified with a @type={"controlled", "fixed"}.

[1] https://trac.railml.org/ticket/431

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railMl2] Proposal for new attribute @switchable in <baliseGroup> and wiki refinement [message #2719 is a reply to message #2697] Thu, 20 May 2021 12:34 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 156
Registered: March 2016
Senior Member
If @switchable should be on the <balise> or on the <baliseGroup> depends if the attribute is meant to be physical (on the balise) or on the logical level forming a variable message (on the baliseGroup).

We think it should describe both, so we suggest placing it on the balise. This is in line with @switchable being on the signal and not on the signal's aspect/route. Also, the reference/use of a <balise> is mandatory so the placement on the <balise> would not force the use of a <balise> if you need to indicate @switchable for a <baliseGroup>. Further this would give the additional information which of the individual balises are switchable. Usually in a balise group with variable messages only the first balise is switchable (relaying the signal aspect).

Bane NOR agrees also to this with the argument that the same information is also on the balise and not on the baliseGroup in railML3.2. The terms for the attribute and its values are different, but the placement is the same: railML2.5 balise@switchable="yes/no" = railML3.2 balise@type="controlled/fixed"

Re: [railMl2] Proposal for new attribute @switchable in <baliseGroup> and wiki refinement [message #2725 is a reply to message #2719] Fri, 21 May 2021 14:29 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Torben,

thank you for your feedback. I updated/corrected the Track ticket #431 accordingly: balise (and not baliseGroup) shall be switchable.

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railMl2] Proposal for new attribute @switchable in <baliseGroup> and wiki refinement [message #2726 is a reply to message #2725] Fri, 21 May 2021 15:47 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Torben, dear all,

in order to be quite close to the railML 3.x model, I suggest to modify the approach:

Instead of <balise>@switchable, we can also define a new attribute <balise>@type with values "controlled" and "fixed".

What do you think?

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railMl2] Proposal for new attribute @switchable in <baliseGroup> and wiki refinement [message #2731 is a reply to message #2726] Fri, 21 May 2021 18:24 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 156
Registered: March 2016
Senior Member
Christian Rahmig <coord(at)infrastructurerailMLorg> wrote:
> Dear Torben, dear all,
>
> in order to be quite close to the railML 3.x model, I
> suggest to modify the approach:
>
> Instead of <balise>@switchable, we can also define a new
> attribute <balise>@type with values "controlled" and
> "fixed".
>
> What do you think?
>
> Best regards
> Christian

Dear Christian,

This makes sense.
Also I will not bicker with the coordinators when it comes to the terms..
;-)

--
TOBR
Re: [railMl2] Proposal for new attribute @switchable in <baliseGroup> and wiki refinement [message #2737 is a reply to message #2731] Fri, 28 May 2021 12:24 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Torben,

thank you for your feedback. The railML solution proposal in Trac ticket #431 has been adapted accordingly and the solution will be implemented with railML 2.5.

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Previous Topic: [railML3]: operationalPoint of operationalType="block"
Next Topic: Suggested definition of <ocpVis>
Goto Forum:
  


Current Time: Thu Mar 28 20:43:18 CET 2024