|
|
|
|
|
|
| Re: Designator for geometry elements [message #3801 is a reply to message #3745] |
Mon, 01 December 2025 11:49   |
christian.rahmig
Messages: 530
Registered: January 2016
|
Senior Member |
|
|
Dear Torben, Mathias and Dominik,
thanks for bringing up this topic. In general I like the idea of having potential designators for all elements in my structure. The question to be answered in this context: what do we want to model with it? Is there an external register, where for example the gradientCurves can link to? Can anyone of you provide an example please.
Concerning the elementState: The current values of elementState cover very good the lifecycle of physical infrastructure from an operational perspective. How shall we handle this if we transfer the elementState topic to "virtual" objects like netElements? Shall we maybe define a smaller subset of possible values? In order to answer this question, it is also for this topic very important to know what is the intention behind? What shall be modelled with a netElement's elementState?
Any feedback is highly appreciated.
Best regards
Christian
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: Designator for geometry elements [message #3803 is a reply to message #3801] |
Tue, 02 December 2025 12:54 |
Milan Wölke
Messages: 214
Registered: April 2007
|
Senior Member |
|
|
Hi all,
first, I would like to suggest to separate the two discussions here. The one is regarding <elementState>, the other regarding <designator>. As this started with <designator> I would propose to keep this thread on track and expand on this topic.
From my point of view it is very interesting to see that the coordinators recently discussed to consider removing the designators from abstract entities such as netElements, not only but also because they are actually not forseen in the RTM.
As such I would also ask you to let us know what your intended purpose for these designators is? When do you think it is useful? After all for entities like netElements and geometry elements it is very likely that two systems will not have the same way of modelling the same information. As such, I would assume that it is not very probable, that the information would survive an import into another than the exporting system.
Best regards, Milan
Milan Hoffmann – Timetable schema coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
|
|
| Re: Designator for geometry elements [message #3815 is a reply to message #3810] |
Fri, 05 December 2025 17:43 |
Thomas Nygreen
Messages: 110
Registered: March 2008
|
Senior Member |
|
|
Dear all,
I share Milan's concern regarding identifying abstract entities, but the identification of all elements is a much broader and very different scope from the request that Torben initially made here. And as Mathias himself points out, that discussion is better addressed by his proposal to introduce a global identifier. So I suggest not continuing that discussion here, but in the thread Mathias linked to.
Regarding Torben's original request for designators on geometry elements, I can answer Christian's question about examples. Yes, the railML-recognised register BaneData contains object IDs for both gradient curves and horisontal curves. However, for gradients only the arcs are represented, with the constant gradients between them being a property of both the previous and the next arc. Still, for the arcs, BaneData can provide unique designators. (As Milan notes, this is likely modelled differently in other systems, so the designators or global identifiers may not survive a full round-trip unless the two systems are coordinated.)
Secondly, Torben points to a previous discussion about elementState, where Jernbanedirektoratet and Bane NOR disagreed with the outcome. That topic was concluded more than a year ago, so the discussion may as well continue here, but no new information has been provided so far. I agree with Christian that it is important to know what the intended use is.
Best regards,
Thomas
Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
Members
Search
Help
Login
Home
