|
|
| Re: Missing attributes and maybe elements in railML3.2 for RTCI-a [message #3145 is a reply to message #3133] |
Wed, 18 October 2023 17:33   |
christian.rahmig
Messages: 436
Registered: January 2016
|
Senior Member |
|
|
Dear Torben,
thank you very much for your specific proposals on extending railML 3 data model w.r.t. RTCI use case requirements. Let me comment on them one by one:
(1) tunnel resistance
Adding the attributes @resistanceFactorPassenger and @resistanceFactorFreight to element <overCrossing> seems to be a straightforward adaptation of railML 3 data model [1]. However, it is only half of the solution railML 2.5 provides, where a tunnel resistance can also be calculated from wall material and tunnel cross-section. So, dear community, are you fine with just the tunnel resistance factors, or do you need wall material and tunnel cross-section, too?
(2) Electrification change
Electrification related parameters can be linked with the railway network (topology) by <electrificationSection> elements and their <*Location> child elements. For microscopic modelling, you would most likely use <linearLocation>, but it is also possible to aggregate a bigger number of netElements with an <areaLocation> and thus define a certain electrification setting in a rather "macroscopic style". It is also possible to use <networkLocation> to link the electrification section with a complete network (level). So, you are very flexible here.
(3) Train protection system change
The concept for train protection system changes is similar to the electrification change issue in (2). Maybe, the term "trainProtectionSection" would be better than "trainProtectionElement" if we want to describe a certain train protection system setting in a rather macroscopic style. So, dear community, what do you think: do we need an <trainProtectionSection> in addition to a <trainProtectionElement> or shall we rename <trainProtectionElement> into <trainProtectionSection> or shall we leave everything as it is?
(4) Operational rules
This element is not part of railML 3.2 data model as it was not required by the use cases that have been implemented so far. So, if RTCI needs operational rules, we are free to extend the model with the most appropriate solution. Is there anyone from the community, who needs operational rules as well, and if so, for which use case?
Thank you very much and best regards
Christian
[1] https://www.railml.org/forum/index.php?t=msg&th=486& goto=1460&#msg_1460
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: Missing attributes and maybe elements in railML3.2 for RTCI-a [message #3172 is a reply to message #3145] |
Thu, 07 December 2023 13:02 |
Thomas Nygreen
Messages: 68
Registered: March 2008
|
Member |
|
|
christian.rahmig wrote on Wed, 18 October 2023 17:33
(3) Train protection system change
The concept for train protection system changes is similar to the electrification change issue in (2). Maybe, the term "trainProtectionSection" would be better than "trainProtectionElement" if we want to describe a certain train protection system setting in a rather macroscopic style. So, dear community, what do you think: do we need an <trainProtectionSection> in addition to a <trainProtectionElement> or shall we rename <trainProtectionElement> into <trainProtectionSection> or shall we leave everything as it is?
To add some context for the community, railML 2 has both trainProtectionElement (for individual magnets etc.) and trainProtectionChange (for points where something about the system changes). These elements are syntactically quite similar, the main difference being that trainProtectionChange has an attribute to specify if the monitoring is intermittent, continuous or none at all. That same attribute is also present in the railML 3 element trainProtectionElement, so syntactically it has the capabilities of both the two elements from railML 2.
If we decide to use the same element for both purposes, I think we need a name that does not contain either Element or Section, as they both indicate a specific usage.
Best regards,
Thomas
Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
|
| Re: Missing attributes and maybe elements in railML3.2 for RTCI-a [message #3180 is a reply to message #3172] |
Thu, 04 January 2024 13:41 |
Morten Torstensen
Messages: 1
Registered: October 2023
Location: Oslo, Norway
|
Junior Member |
|
|
We in Bane NOR need Operational rule references in order to do runtime calculations, because some rules affect the max allowed speed of trains in some cases. We should look into exactly how it should be modeled.
Morten Torstensen
Bane NOR - Norwegian Infrastructure Manager
Digital Information Model for railway infrastructure
Ontology, modeling, mapping
|
|
|
|
Members
Search
Help
Login
Home
