| Re: [railml3] Signal types and functions [message #2145 is a reply to message #2138] |
Tue, 12 February 2019 14:34   |
Thomas Nygreen JBD
Messages: 68
Registered: February 2017
|
Member |
|
|
Dear Christian and Tobias,
christian.rahmig wrote on Mon, 11 February 2019 15:51
The idea was to provide
the information on two levels:
- high level (only one word): using attribute <signalIS>@type
- detailed level: using child element <signalIS><is*Signal>
Depending on the requirements resulting from the use case, the
information about the signal shall be modelled either in one way or the
other.
In my opinion the combined approach leaves the type attribute completely redundant. As posted above I suggest to remove it and only use the child elements. If more detailed information is not available, the element may be empty. Keeping both leaves two separate ways to model the same information, increasing the load on both reading and writing systems.
christian.rahmig wrote on Mon, 11 February 2019 15:51
Yes, <signalIS>@type is far away from being complete. But the list can
be extended due to the "otherEnumerationValue" extension.
Yes it can be extended but those values will not have a coordinated interpretation. Now that the most important values have found other homes, I think the attribute can be removed, as already suggested.
christian.rahmig wrote on Mon, 11 February 2019 15:51
"board" can be considered as a new value for
<signalIS><signalConstruction>@type. It will be defined as a
"non-switchable semaphore signal". The enumeration value "semaphore"
would be used for switchable semaphore signals. Are there any examples
for non-switchable virtual signals?
I do not understand why you consider a board to be a semaphore signal. A semaphore, by definition, conveys its meaning using the positions of its arms. A board is a separate signal type. It has no arms and does not fit the definition of a semaphore. Is this a German generalisation? Also, Tobias shows an example of a non-switchable semaphore (which is not a board).
Even if only one of Tobias' examples is a semaphore, he illustrates well the use of different types of non-switchable and non-board signals. In Norway these would be separate signal types, but I agree that there is a use case for @switchable. This probably also removes the need for a <signalConstruction>@type="lamp" value. However, the documentation has to be amended so that @switchable="false" does not necessarily imply a panel/board.
Best regards,
Thomas Nygreen
Railway capacity engineer
Jernbanedirektoratet
|
|
|
|
Members
Search
Help
Login
Home
