Forum - RDF feed
https://www.railml.org/forum/index.php
Re: Are designator start- and end-date in railml 3.2 missing?
https://www.railml.org/forum/index.php?t=rview&goto=3181&th=933#msg_3181
I am not sure why we did not continue the startDate and endDate attributes on the designator type in 3.x. This affects designators in general, not only for projects. Note that the start and end dates apply only to the designator, not to the parent object (such as a project). I will follow up with the other coordinators.
trafIT solutions gmbh
Heinrichstrasse 48
8005 Zürich
Switzerland
]]>Matthias Cavigelli2023-11-21T10:51:55-00:00Regarding changes in SpeedProfile.Load in RailML v 3.3
https://www.railml.org/forum/index.php?t=rview&goto=3166&th=932#msg_3166
I am in need of some help/clarification.
With the release of RailML 3.3 the the SpeedProfile attributes "maxAxleLoad" and "maxMeterLoad" will be replaced by "exceedsAxleLoad" and "exceedsMeterLoad".
This is causing some questions regarding how to implement the Load Element in UC:NEST as I interpret this change as a switch to a minimum load limit instead of a maximum load limit.
The data I have available are the classes of maximum allowed loads for my network.
If someone could explain the new attributes and perhaps also how to convert the "maxAxleLoad" and "maxMeterLoad" values into values that would fit the new attributes I would be very greatful?
Thanks in andvance
Jonas Ekman
Swedish Transport Administration
]]>Jonas Ekman2023-11-14T08:46:42-00:00Re: Vote for revision of ISO RailDax
https://www.railml.org/forum/index.php?t=rview&goto=3161&th=930#msg_3161
Správa železnic votes for option A ( i.e. Sept 2025)
Správa železnic (SZCZ) is infrastructure manager in the Czech Republic and has implemented railML 3.x format for publication of network statement data and other purposes. SZCZ is member of RailNetEurope (RNE) - association of European infrastructure managers. RNE will use ISO RailDax for date exchange about infrastructure with its member. Existing RailDax is based on railML 2.x.
SZCZ has no expierence with railML 2.x. Therefore SZCZ would appreciate if new version of RailDax railML based on version 3.x would be available as soon as possible. That is why therefore SZCZ supports option A.
Miloš Futera
]]>Miloš Futera2023-11-08T08:48:16-00:00Re: Vote for revision of ISO RailDax
https://www.railml.org/forum/index.php?t=rview&goto=3155&th=930#msg_3155
This as it fits with our resource plan where we will focus on railML 3.2 mapping/3.3 development to fulfil all required UC for Jernbanedirektoratet and gain further maturity in 2024. We do not have enough resources to also contribute to an ISO RailDax revision at the same time.
We also think a revision of ISO RailDax would fit well with the development of railML version 3.4, making railML3.4 the basis for ISO IS4398:2028 (our proposal).
]]>Torben Brand2023-11-01T07:27:08-00:00Vote for revision of ISO RailDax
https://www.railml.org/forum/index.php?t=rview&goto=3154&th=930#msg_3154
As a technical specification (TS) it is intended for review after 3 years. So, there will be a ballot on the manner in ISO technical committee 204 intelligent transportation systems. National standardisation bodies (NSB) that are member of TC204 in September 2025 will be eligible to vote. The vote is: abstain, discontinue, or revise. The most common vote is to abstain. This means the technical specification continues unchanged as an ISO TS. Alternative the NSB can vote to discontinue the standard (requiring an argument) or vote to revise it towards a full international standard (IS). A simple majority decides the vote. If there is no initiative (from railML or other ISO participants) the very likely outcome is that the TS continues unchanged. The next vote is then 3 years later in September 2028. If an ISO participant suggests revising the TS, they need to commit resources to do the revision and achieve the necessary simple majority vote. Also, a draft of the proposed revision should be made. Because of this work an active decision to revise needs to be made at least 1,5 years prior to the vote. For the upcoming vote this would be March 2024. The railML conference closest before this date is the upcoming conference in Rome on 7th November.
Thus, I suggest the railML community make an active decision to recommend a revision of ts4398 RailDax for either:
A. Sept 2025
B. Sept 2028 (without any commitment)/No revision planned currently.
There seems to be consensus if we want a revision, it should be based on the latest version of railML3.
Please cast your vote as a reply to this forum post. Note if you vote to revise you should contribute to the revision work.
]]>Torben Brand2023-10-31T14:54:20-00:00Re: railVIVID issue with footnotes in the tabular timetable
https://www.railml.org/forum/index.php?t=rview&goto=3150&th=917#msg_3150
Looking forward to your analysis.
Best regards,
Thomas Imboden]]>Thomas Imboden2023-10-26T14:13:36-00:00Re: railVIVID issue with footnotes in the tabular timetable
https://www.railml.org/forum/index.php?t=rview&goto=3147&th=917#msg_3147
Thank you very much for the information about footnotes in the tabular/customers timetable and the enquiry about railVIVID as well as the railML data sent in for analysis. Basically, railVIVID as a pure viewing programme can only display the data that is directly available in the railML files.
We will analyse the data provided and ask for a little patience. We apologise for the delay in responding.
By the way, welcome to the railML community.
Best regards,
--
Vasco Paul Kolmorgen - Governance Coordinator
railML.org e.V. (Registry of Associations: VR 5750)
Phone railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany ]]>Vasco Paul Kolmorgen2023-10-20T17:02:01-00:00Re: Use railML to model parts of a large network
https://www.railml.org/forum/index.php?t=rview&goto=3136&th=895#msg_3136
railML.org and its partners actively developed approaches to split and connect the railway network this year. The intermediate result is two approaches: placeholder and connector published in a paper at the conference [1].
railML.org partners (Siemens, Thales, PSI Transcom GmbH) have also proposed their own approaches: intrinsic coordinate, splitting of functional infrastructure elements, etc.
Currently, the connector approach of [1] is being implemented and somehow worked to split and connect railway lines for routes that combine them. However, during the meeting of the NEST working group, it happened that there is a reverse task to split the railway network into lines.
The planned result of the development process is a set of guidelines published at wiki unifying splitting and connecting infrastructure.
Thus, please provide some example data and use cases for splitting (input, desired output, e.g. we have a network in one file but want to have a single line per file) to generalise the developed tool (future guidelines).
This request is related to both railML2 and railML3 users as a tool is closely related to the railML ontology development process [2] i.e. allows for splitting railML2 files after their transformation to railML3.
Summarising all the above there is an ongoing development of guidelines to split and connect infrastructure and railML.org kindly asks you to provide your use cases.
Sincerely,]]>Larissa Zhuchyi2023-09-29T12:49:43-00:00RailML viewer issue
https://www.railml.org/forum/index.php?t=rview&goto=3115&th=917#msg_3115
We tried to read our railML data for the first time with the railML viewer "railVIVID". It works pretty well except for the footnote data, which in our case contains information on the operating hours (is shown in the yellow markers in the screenshot). According to the person responsible for the timetable, this data is exported correctly. Now I hope for help from you specialists, if it is obvious for you where the problem could be. The display of the operating data would be a great relief for us. Please find the RailML export attached as well.
Thank you very much in advance for your help.
Best,
Thomas Imboden, Jungfrau Railways, Switzerland]]>Thomas Imboden2023-08-24T06:52:11-00:00