Home » railML newsgroups » railML.infrastructure » Balise / baliseGroups : structure & attributes
Balise / baliseGroups : structure & attributes [message #329] Wed, 04 July 2012 19:23 Go to next message
pierre.simon is currently offline  pierre.simon
Messages: 8
Registered: July 2012
Junior Member
Conceptually a balise belongs to one and only one balise group. So why not
create the parent node <baliseGroup> having a list of 1..8 balises ?
On top of that, attributes like countryID which today is attached to
<balise> could be move the parent node <baliseGroup> (+ some additional
attributes like
- idBaliseGroup
- its type (in Belgium we have Infill Balise Group / Signal Balise Group /
Technical Fixed Balise Group / Technical Switchable Balise Group)
- its reference to the signal (xs:IDRef)

Plus a balise group will have some function(s) and textMessage(s)

For instance we can have:
<baliseGroup id="id1" name="d" pos="4" dir="up" absPos="4"
application="ETCS" nidBg="1" nidC="251" type="IBG" signalRef="id12873">
<balise baliseType="Fixed" nPig="1"/>
<balise baliseType="Switchable" nPig="0"/>
</baliseGroup>

Is it possible to review the model of the <baliseGroup> element in the
next railML version ?

[de: Eine Balise gehoert immer zu einer Balisengrppe. Somit koennte man
Attribute der Balisen in die Balisengruppe verschieben, um sie nicht in
der Balise zu wiederholen. Es koennen bis zu 8 Balisen pro Balisengruppe
erscheinen.]

--
----== posted via PHP Headliner ==----
Re: Balise / baliseGroups : structure & attributes [message #338 is a reply to message #329] Thu, 05 July 2012 06:12 Go to previous messageGo to next message
Christian Rahmig is currently offline  Christian Rahmig
Messages: 151
Registered: January 2011
Senior Member
Hello Pierre,

> Conceptually a balise belongs to one and only one balise group. So why not
> create the parent node <baliseGroup> having a list of 1..8 balises ?
> On top of that, attributes like countryID which today is attached to
> <balise> could be move the parent node <baliseGroup> (+ some additional
> attributes like
> - idBaliseGroup
> - its type (in Belgium we have Infill Balise Group / Signal Balise Group /
> Technical Fixed Balise Group / Technical Switchable Balise Group)
> - its reference to the signal (xs:IDRef)

the grouping of <balise> elements within a <baliseGroup> instead of
referencing the balises from the balise group is a change that is only
possible with a next major release 3.0. However, it is very useful to
define the attributes of a <balise> element within a <baliseGroup> as
well. And in case we define these attributes being optional, it will be
possible to implement them with railML 2.2.

> Plus a balise group will have some function(s) and textMessage(s)

What kind of functions do you think about? Can you please give an
example here?

> For instance we can have:
> <baliseGroup id="id1" name="d" pos="4" dir="up" absPos="4"
> application="ETCS" nidBg="1" nidC="251" type="IBG" signalRef="id12873">
> <balise baliseType="Fixed" nPig="1"/>
> <balise baliseType="Switchable" nPig="0"/>
> </baliseGroup>

Can you please provide some description for the parameters you used
within this example? It would be helpful for the readers to understand
the actual problem. Thank you very much.

Regards

---
Christian Rahmig
railML.infrastructure coordinator
Re: Balise / baliseGroups : structure & attributes [message #411 is a reply to message #338] Sat, 27 October 2012 13:00 Go to previous messageGo to next message
Christian Rahmig is currently offline  Christian Rahmig
Messages: 151
Registered: January 2011
Senior Member
Dear Pierre and other railML users,

>> Conceptually a balise belongs to one and only one balise group. So why
>> not
>> create the parent node <baliseGroup> having a list of 1..8 balises ?
>> On top of that, attributes like countryID which today is attached to
>> <balise> could be move the parent node <baliseGroup> (+ some additional
>> attributes like
>> - idBaliseGroup
>> - its type (in Belgium we have Infill Balise Group / Signal Balise
>> Group /
>> Technical Fixed Balise Group / Technical Switchable Balise Group)
>> - its reference to the signal (xs:IDRef)
>
> the grouping of <balise> elements within a <baliseGroup> instead of
> referencing the balises from the balise group is a change that is only
> possible with a next major release 3.0. However, it is very useful to
> define the attributes of a <balise> element within a <baliseGroup> as
> well. And in case we define these attributes being optional, it will be
> possible to implement them with railML 2.2.

based on your forum entry, I created a trac ticket [1] summarizing the
proposed modification of the <baliseGroup> for railML 2.2. Please have a
look at it and reply here whether the following attributes fulfill your
requirements:

- A <baliseGroup> is modelled as an element with ID and name and
therefore inherits the parameters id, name and code.

- A <baliseGroup> fulfills a certain function, which will be defined
in the parameter "type" with the possible values 'infill', 'signal',
'technicalFixed' and 'technicalSwitchable'.

- A <baliseGroup> may have a reference to a <signal>, which will be
defined in the optional parameter "signalRef".

- The reference from a <baliseGroup> to up to eight single <balise>
elements remains with the sequence of <baliseRef> objects.

[1] https://trac.assembla.com/railML/ticket/174

Regards

--
Christian Rahmig
railML.infrastructure coordinator
Re: Balise / baliseGroups : structure & attributes [message #414 is a reply to message #411] Wed, 31 October 2012 23:09 Go to previous messageGo to next message
Susanne Wunsch railML is currently offline  Susanne Wunsch railML
Messages: 0
Registered: January 2020
Dear Christian, Pierre and other railML users,

Christian Rahmig <coord(at)infrastructurerailmlorg> writes:
>>> Conceptually a balise belongs to one and only one balise group. So why
>>> not
>>> create the parent node <baliseGroup> having a list of 1..8 balises ?
>>> On top of that, attributes like countryID which today is attached to
>>> <balise> could be move the parent node <baliseGroup> (+ some additional
>>> attributes like
>>> - idBaliseGroup
>>> - its type (in Belgium we have Infill Balise Group / Signal Balise
>>> Group /
>>> Technical Fixed Balise Group / Technical Switchable Balise Group)
>>> - its reference to the signal (xs:IDRef)

> - A <baliseGroup> is modelled as an element with ID and name and
> therefore inherits the parameters id, name and code.

+1

> - A <baliseGroup> fulfills a certain function, which will be defined
> in the parameter "type" with the possible values 'infill', 'signal',
> technicalFixed' and 'technicalSwitchable'.

That above mentioned types are of different kind. A "signal" balise
group is always "technicalSwitchable". The "infill" balise group is also
always "technicalSwitchable". A "technicalFixed" balise group may be one
for odometry or for track conditions ...

Thus I would prefer the enumeration values "infill", "signal" and
"fixed" for the "type" attribute.

> - A <baliseGroup> may have a reference to a <signal>, which will be
> defined in the optional parameter "signalRef".

On another thread we currently discuss the reference from a signal to
its "train protection element". I would prefer to go the same way here.

Thus there could be a reference from a signal to its "protecting" balise
group with a "baliseGroupRef" attribute in <signal> or <signalAspect>.

> - The reference from a <baliseGroup> to up to eight single <balise>
> elements remains with the sequence of <baliseRef> objects.

As mentioned at the beginning of this thread the main idea was to define
the up to eight balises inside the balise group not referring them
outside. A balise of a balise group cannot be used otherwise by another
balise group. Some attributes of the current <balise> element should
move to the <baliseGroup> element in order to reduce not-needed
redundancy.

> [1] https://trac.assembla.com/railML/ticket/174

Kind regards...
Susanne

--
Susanne Wunsch
Schema Coordinator: railML.common
Re: Balise / baliseGroups : structure & attributes [message #429 is a reply to message #414] Sat, 10 November 2012 00:15 Go to previous messageGo to next message
Christian Rahmig is currently offline  Christian Rahmig
Messages: 151
Registered: January 2011
Senior Member
Dear Susanne and other railML users,

>> - A <baliseGroup> fulfills a certain function, which will be defined
>> in the parameter "type" with the possible values 'infill', 'signal',
>> technicalFixed' and 'technicalSwitchable'.
>
> That above mentioned types are of different kind. A "signal" balise
> group is always "technicalSwitchable". The "infill" balise group is also
> always "technicalSwitchable". A "technicalFixed" balise group may be one
> for odometry or for track conditions ...
>
> Thus I would prefer the enumeration values "infill", "signal" and
> "fixed" for the "type" attribute.

Ok, I modified the trac ticket [1] accordingly.

>> - A <baliseGroup> may have a reference to a <signal>, which will be
>> defined in the optional parameter "signalRef".
>
> On another thread we currently discuss the reference from a signal to
> its "train protection element". I would prefer to go the same way here.
>
> Thus there could be a reference from a signal to its "protecting" balise
> group with a "baliseGroupRef" attribute in <signal> or <signalAspect>.

Ok. See the trac ticket changes in [1].

>> - The reference from a <baliseGroup> to up to eight single <balise>
>> elements remains with the sequence of <baliseRef> objects.
>
> As mentioned at the beginning of this thread the main idea was to define
> the up to eight balises inside the balise group not referring them
> outside. A balise of a balise group cannot be used otherwise by another
> balise group. Some attributes of the current <balise> element should
> move to the <baliseGroup> element in order to reduce not-needed
> redundancy.

Yes, it is useful to group the balise objects in <baliseGroup> than
grouping references there. However, this will be a major change if you
do not want to have two (legal) places for defining <balise> elements.
Therefore, I prefer to change this with railML 3.0.

[1] https://trac.assembla.com/railML/ticket/174

Regards

--
Christian Rahmig
railML.infrastructure coordinator
Re: Balise / baliseGroups : structure & attributes [message #513 is a reply to message #429] Mon, 04 February 2013 12:21 Go to previous message
Christian Rahmig is currently offline  Christian Rahmig
Messages: 151
Registered: January 2011
Senior Member
Dear Susanne and other railML users,

Am 10.11.2012 00:15, schrieb Christian Rahmig:
>>> - A <baliseGroup> may have a reference to a <signal>, which will be
>>> defined in the optional parameter "signalRef".
>>
>> On another thread we currently discuss the reference from a signal to
>> its "train protection element". I would prefer to go the same way here.
>>
>> Thus there could be a reference from a signal to its "protecting" balise
>> group with a "baliseGroupRef" attribute in <signal> or <signalAspect>.
>
> Ok. See the trac ticket changes in [1].

With the latest commit the new optional attribute "baliseGroupRef" has
been implemented for the <signal> element. In parallel the attribute
"signalRef" has been removed from the <baliseGroup> element.

> [1] https://trac.assembla.com/railML/ticket/174

Regards

--
Christian Rahmig
railML.infrastructure coordinator
Previous Topic: speed profiles and braking percentages
Next Topic: speed profiles for general directions
Goto Forum:
  


Current Time: Thu Mar 28 22:35:03 CET 2024