Home » railML newsgroups » railML.infrastructure » [railML3.3] Signal combinations
Re: [railML3] Re: Signal combinations [message #3202 is a reply to message #3163] Fri, 08 March 2024 09:57 Go to previous messageGo to previous message
Torben Brand is currently offline  Torben Brand
Messages: 225
Registered: March 2016
Senior Member
Both suggested models for signal combinations (with use of signalIL and signal IS) has its limitations and/or would need extensions. As a solution I suggest a third option, that is in line with the latest modelling decisions [2],[1] (also see attached illustration):

Options (1 and 2 as described in previous post):
1. As suggested in Jörg's example in Rome (also option 1 in previous post by Jörg)
Signals are combined through reference from separate signalIL signals to signalIS<isMovemetSignal> for the complete combination of signals. Missing <typeDesignator> in signalIL to declare the individual signals.

2. Use of todays model with combinations for minimum change. (also option 2 in previous post by Jörg)
As option 3, but with empty <isMovementSignal> element and use signalIL@function to define the movement signal type with existing value interpretation.

3. Modelling principle where all physical aspects are in signalIS and all interlocking in signalIL.
Make new @type attributes in <isMovemetSignal>. This is already an ongoing task. [1] Then the individual signals of the signals combination can be defined in signalIS and the combination made with the attribute signalIS@belongsToParent

Pro/con analysis:
I would recommend solution 3.

1. This would break with the principle that physical characteristics are in signalIS and also have the <typeDesignator> for signals at two different locations in the schema. Also "repeater" and "distant" are both signalIL@function values. So for a combination og repeater and distant (de:"Vorsignalwiederholer") you would need to deprecate the "repater" value and add new attribute @isRepeater. So I would not recommend this solution
2. Same arguments as for solution A) except the need to make new <typeDesignator>. So I would not recommend this solution
3. Is in line with the decision [1] and [2] to have the physical aspects in signalIS and the additional interlocking attributes in signalIL and minimize new extensions (beyond those already agreed in <isMovementSignal>)

[1] https://www.railml.org/forum/index.php?t=msg&th=899& goto=3201&#msg_3201
[2] https://www.railml.org/forum/index.php?t=msg&th=649& goto=3200&#msg_3200

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: How do you model operational points inside operational points in mesoscopic topology?
Next Topic: [railML3] @lateralSide and @verticalSide and distances
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Mon Oct 12 08:30:18 GMT+2 2026