| Re: [railML2] Clearer modelling of the signal designation [message #2342 is a reply to message #2320] |
Tue, 25 February 2020 10:21   |
Torben Brand
Messages: 158
Registered: March 2016
|
Senior Member |
|
|
Excellent suggestion!
Since there is no <designator> in railML2 except for OCPs We in Norway use @code for the designator @entry value. The register is then a fixed national register ("Banedata"). @code then forms a unique individual identifier (UID). In railML3 this will be fixed.
I would, though, suggest changing the value in your example from @code="A1" to something that resembles a UID. Since A1 probably is not unique.
I would also take the opportunity to focus this thread on the clear modelling of the board value (which is also highly applicable for railML3):
We handle the @name as described in the wiki "Established, human-readable short string, giving the object a name. Not intended for machine interpretation, please see our notice on human interpretable data fields.". So, the @name value follows no semantic constraint and is thus variable in it's semantics and not machine readable and interpretable. But we need to model the specific text on the board bellow the signal in a precise way. Shall this be done with a second signal (on the same @pos) with @switchable="false" and @name=[board text value] ("20 ZS3" in the example above). Or do we need an extension attribute @boardValue="string"?
[Updated on: Tue, 25 February 2020 11:29] Report message to a moderator |
|
|
|
Members
Search
Help
Login
Home
