Home » railML newsgroups » railML.infrastructure » railML 2.3 infrastructure extension for capacity planning and network statement usecases (railML 2.3 infrastructure extension for capacity planning and network statement usecases)
railML 2.3 infrastructure extension for capacity planning and network statement usecases [message #1454] Tue, 20 December 2016 18:21 Go to next message
Torben Brand is currently offline  Torben Brand
Messages: 156
Registered: March 2016
Senior Member
Dear railML infrastructure forum,
As the railML3 implementation takes a bit longer, Jernbaneverket has looked into fulfilling the absolute requirements of its capacity planning and network statement use case with railML2.3 extensions. The study has shown that the use case can be fulfilled within the frame of "any" element extensions and further "other" attribute definitions that may become part of the emerging railML3 schema. All extension requirements are based on these use cases.
The following existing 7 elements in railML2.3 were extended:
• controller
• trackGroups
• propOperational
• ocsElements
• switch/crossing
• signal
• tunnel
I will post separate postings for the 7 items here in the forum.
All extensions are part of the "NO" namespace that will be defined in a xsd later.
All extended elements or extended attributes to an existing element have been implemented with the namespace prefix "NO:". The prefix can of course later be removed when the extended object would be included in the standard.
All belonging attributes to an extended element have no prefix.
All extended values to existing attributes have been implemented with the prefix "other:".
Extended elements, attributes and values that seem universal have been implemented in English language.
Extended elements, attributes and values that seem Norwegian specific have been implemented in Norwegian language. Values that seem Norwegian specific also have the prefix:"NO:", to clearly mark than as a national parameter.

Kind regards
Torben Brand, Jernbaneverket (from 1.1.2017 Jernbanedirektoratet the Norwegian railway directorate - http://jernbanedirektoratet.no/en/about-us/Wink
Re: railML 2.3 infrastructure extension for capacity planning and network statement usecases [message #1463 is a reply to message #1454] Mon, 02 January 2017 17:28 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Torben,
dear railML community,

Am 20.12.2016 um 18:21 schrieb Torben Brand:
> Dear railML infrastructure forum,
> As the railML3 implementation takes a bit longer,
> Jernbaneverket has looked into fulfilling the absolute
> requirements of its capacity planning and network statement
> use case with railML2.3 extensions. The study has shown that
> the use case can be fulfilled within the frame of "any"
> element extensions and further "other" attribute definitions
> that may become part of the emerging railML3 schema. All
> extension requirements are based on these use cases. The following
> existing 7 elements in railML2.3 were
> extended:
> • controller
> • trackGroups
> • propOperational
> • ocsElements
> • switch/crossing
> • signal
> • tunnel
> I will post separate postings for the 7 items here in the
> forum.
> [...]

Before I am going to answer on your separate postings in detail, please
let me thank you for sharing your ideas here in the railML forum with
the railML user and developer community. Contributions like yours are
very important for the further development of railML, especially for the
approaching railML v3.

The proposals are based on railML v2.3. As stated earlier there will be
no railML v2.4 with just infrastructure scheme changes. However, if
there is a decision to go for a railML v2.4 (pushed by requirements of
the timetable schema), how do you want to handle the proposed changes?
Do you want to see them implemented in railML v2.4 or better in v3?

Last, but not least: Happy New (Railway) Year to everyone!

Best regards
Christian

--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: railML 2.3 infrastructure extension for capacity planning and network statement usecases [message #1508 is a reply to message #1463] Fri, 24 February 2017 14:45 Go to previous message
Torben Brand is currently offline  Torben Brand
Messages: 156
Registered: March 2016
Senior Member

>The proposals are based on railML v2.3. As stated earlier there will be
>no railML v2.4 with just infrastructure scheme changes. However, if
>there is a decision to go for a railML v2.4 (pushed by requirements of
>the timetable schema), how do you want to handle the proposed changes?
>Do you want to see them implemented in railML v2.4 or better in v3?


I suggest to implement the suggested element extensions in both railML 2.4 (if developed) and in railML3. This as they must be part of railML3 as they are part of the capacity planning use case. Both implementations have benefits and disadvantages. railML 2 is available, tested, extensions are relatively simple and the model is relative simple to implement. RailML3 has more functionality, but the model is not developed and tested fully and is more complex. Thus I recommend a parallel approach.
Some of the elements suggested her border towards the interlocking schema. They all derive from the capacity planning use case. And thus they describe, in our perspective, more the interlocking's operational functionality than a technical description. We need to solve as much of this use case as possible as soon as possible. Thus we suggest using the proposed extensions in railML2 infrastructure.
Previous Topic: [railML3|alpha] Missing track conditions
Next Topic: railml 2.3 Export only updated data from a data source
Goto Forum:
  


Current Time: Fri Mar 29 00:18:25 CET 2024