Home » railML newsgroups » railML.infrastructure » [railML3] Restricting IS:line and RTM:linearPositioningSystem (New semantic constraints suggested)
[railML3] Restricting IS:line and RTM:linearPositioningSystem [message #3224] Wed, 10 April 2024 16:59 Go to next message
Larissa Zhuchyi is currently offline  Larissa Zhuchyi
Messages: 38
Registered: November 2022
Member
Dear all

Based on the issues discovered during the recent certifications of railML3 data and the "new" initiative of railML.org defining best practices for splitting and merging railML3 file, railML.org suggests to introduce new semantic constrains. Please review the suggested semantic constrains IS:006 and IS:014 and provide your comments.

Suggested semantic IS:006 constraint for railML3
each railway line with own mileage should always be associated with its own <linearPositioningSystem>, i.e. Advanced example of railML has three lines with their own mileages, thus should have thee <linearPositioningSystem>s.

Suggested semantic IS:014 constraint for railML3
@startMeasure and @endMeasure are start and end values of a railway <IS:line> associated with <RTM:linearPositioningSystem> not max and min values of a current file with e.g. line section

See the all semantic constraint on the Wiki https://wiki3.railml.org/index.php?title=Dev:Semantic_Constr aints

Thanks in advance.

Sincerely,


Larissa Zhuchyi – Ontology Researcher
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML3] Restricting IS:line and RTM:linearPositioningSystem [message #3231 is a reply to message #3224] Thu, 25 April 2024 20:13 Go to previous messageGo to next message
Michael Gruschwitz is currently offline  Michael Gruschwitz
Messages: 12
Registered: May 2020
Junior Member
Dear Larissa,
dear all,

Thank you for proposing the new semantic constraints IS:006 and IS:014
for railML3. At Bahnkonzept, we specialize in railway infrastructure
surveys, often of only partial lines, and face challenges with the
current constraint IS:014. It assumes definitive start and end values
(@startMeasure and @endMeasure) for a railway line, which isn't always
possible in our operations.

We suggest either providing an alternative to indicate uncertainty in
these measures or considering the removal of this constraint while
retaining IS:006. This adjustment would better support the real-world
scenarios of data providers like us and ensure broader applicability and
accuracy of railML3 data.

We appreciate your attention to this matter and look forward to a
productive discussion.

Best regards,
--
Michael Gruschwitz
Bahnkonzept Dresden/Germany

Am 10.04.2024 um 16:59 schrieb Larysa Zhuchyi:
> Dear all
>
> Based on the issues discovered during the recent
> certifications of railML3 data and the "new" initiative of
> railML.org defining best practices for splitting and merging
> railML3 file, railML.org suggests to introduce new semantic
> constrains. Please review the suggested semantic constrains
> IS:006 and IS:014 and provide your comments.
>
> Suggested semantic IS:006 constraint for railML3
> each railway line with own mileage should always be
> associated with its own <linearPositioningSystem>, i.e.
> Advanced example of railML has three lines with their own
> mileages, thus should have thee <linearPositioningSystem>s.
>
> Suggested semantic IS:014 constraint for railML3
> @startMeasure and @endMeasure are start and end values of a
> railway <IS:line> associated with
> <RTM:linearPositioningSystem> not max and min values of a
> current file with e.g. line section
>
> See the all semantic constraint on the Wiki
> https://wiki3.railml.org/index.php?title=Dev:Semantic_Constr aints
>
> Thanks in advance.
>
> Sincerely,
> --
> Larissa Zhuchyi – Ontology Researcher
> railML.org (Registry of Associations: VR 5750)
> Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML3] Restricting IS:line and RTM:linearPositioningSystem [message #3236 is a reply to message #3231] Mon, 29 April 2024 16:24 Go to previous messageGo to next message
Larissa Zhuchyi is currently offline  Larissa Zhuchyi
Messages: 38
Registered: November 2022
Member
The idea of IS:014 was to try to avoid postprocessing of split file when merging them together issued by either:
- multiple partial linear positioning systems in the merged file or
- one linear positioning system with multiple e.g. @endMeasure attributes.

From what I understand merging may happen even in your use case of surveys. As conceptually what you produce, partitioned files, can be considered as equivalent to split ones. Please correct me if I'm wrong.

How would you handle it if you made incremental surveys and the data would belong to the same railway line?
- introduce one linear positioning system with persistent identifier only in the first measurement trip and then replace @endMeasure every time new data come from the next measurement trip or
- introduce new linear positioning systems every time new data come. Then the railway line will be associated with more then one linear positioning systems.


Larissa Zhuchyi – Ontology Researcher
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML3] Restricting IS:line and RTM:linearPositioningSystem [message #3251 is a reply to message #3236] Thu, 13 June 2024 07:11 Go to previous messageGo to next message
David Lichti is currently offline  David Lichti
Messages: 16
Registered: December 2020
Junior Member
I share Michael's concerns. As a data provider, we could only provide these values for the @startMeasure and @endMeasure attribute by calculating the minimum and maximum of all known linear positions associated to a linear positioning system.

This would not only be computationally quite expensive. The accuracy of these results would also depend on the available infrastructure data covering both end points of the linear positioning system. This is something we have no control over. In our (Hacon/TPS) infrastructure model, linear positioning systems are nothing but a label to specify linear positions. On data import, we do not use explicit value ranges. And on export, we cannot give any reliable and meaningful values.

I, therefore, suggest to make these two attributes optional. This would get around the need to update linear positioning system data when merging data from partial surveys at Bahnkonzept. And it would allow us to use the native linear positioning systems for the POMA use case.

Best regards

David
Re: [railML3] Restricting IS:line and RTM:linearPositioningSystem [message #3254 is a reply to message #3251] Fri, 21 June 2024 12:22 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 447
Registered: January 2016
Senior Member
Dear David and Michael,

thank you for sharing your thoughts/feedback on the proposed semantic constraints.

Looking from a standpoint of unambiguous identification and location, I support the proposal by Larissa. Making the attributes @startMeasure and @endMeasure of a linearPositioningSystem optional is weakening the standard. It is also infecting the RTM where the positioning concept is derived from. So, I would vote for keeping these linearPositioningSystem parameters mandatory, but I am looking forward to receiving more feedback from the community...

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Previous Topic: [railML3] Need for modelling Euroloop
Next Topic: [raillML3] Mounting information of signals
Goto Forum:
  


Current Time: Sat Jul 20 09:34:29 CEST 2024