| 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
|
|
|
|
Members
Search
Help
Login
Home
