Home » railML newsgroups » railml.infrastructure » Suggested definition of <ocpVis> (<infrastructureVisualisation>)
Suggested definition of <ocpVis> [message #2282] Tue, 03 December 2019 12:02 Go to next message
Torben Brand is currently offline  Torben Brand
Messages: 92
Registered: March 2016
Member
Today there is no definition/documentation for the <infrastrucutreVisualisation> scheme in the wiki. The elements and attributes are mapped in the wiki, but there is no definition of the elements and attributes in the wiki.
However there has established itself a best practice of how this schema is used.

I want to point out a specific usage of the sub element <ocpVis>. <ocpVis> distinguished itself from the <trackVis> in that <trackVis> contains the coordinates of the track topology and the elements/objects on the track and <ocpVis> contains the coordinates of all elements NOT part of the tracks (topology or node-edge model). When <infrastructureVisualisation> was created pre railML2.1 the only physical element not part of the tracks was the OCP. Thus, it was logical to name the element <ocpVis>. However, with railML2.1 the controller was introduced. I therefor suggest to also be able to visualise the controller (if need be) with <ocpVis>. To avoid the same constraint later I suggest allowing mapping of all elements in railML, that are not part of the tracks (topology or objects) under <ocpVis>.
Re: Suggested definition of <ocpVis> [message #2286 is a reply to message #2282] Fri, 06 December 2019 19:59 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 273
Registered: January 2016
Senior Member
Dear Torben,

missing documentation in the wiki - especially about best practice usage - is a big problem as its solution is very time and resource consuming. Any help of the community is highly appreciated... We believe that with our partly automated approach in railML 3, the situation of documentation will get better.

But let's come back to your proposal of using <ocpVis> for visualization of controllers and other (non-track-based) elements:

I consider this approach being a temporary solution (until the release of a new railML version), because instead of using <ocpVis> for controllers, I prefer introducing <controllerVis> to be precise on the terms of the elements. Further <*Vis> elements can be easily added later. Another advantage of that approach would be that <*Vis> elements can be indiviually extended with specific visualization information (if they exist).

But I don't want to conclude a solution before we haven't heard further opinions from the community:
Shall we introduce a <controllerVis> element (and further <*Vis> elements in the future) or shall we think of a generic usage of <ocpVis> (maybe to be renamed?Wink? What are your ideas?

Thank you very much and best regards
Christian


Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: Suggested definition of <ocpVis> [message #2350 is a reply to message #2286] Wed, 26 February 2020 16:28 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 92
Registered: March 2016
Member
The norwegian sector apprechiates your suggestion to allow <ocpVis> also for visualisations of <controller>s in railML2.4. We will use it like that in railML2.4.

We are OK with your suggestion to add <controllerVis> and <any> to allow <*Vis> in railML2.5. But we would suggest to rather change <ocpVis> to <objectVis> and use it for any visualisation that is not on the tracks/line. This as its redundant to declare the element type to be visualised as the information is available in the referenced element.
Re: [railML2] Suggested definition of <ocpVis> [message #2354 is a reply to message #2286] Wed, 26 February 2020 20:54 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 273
Registered: January 2016
Senior Member
Dear Torben, dear all,

in order not to forget about this topic, I created a Trac ticket [1] for this issue. For identifying the best solution (for railML 2.4 as well as for railML 2.5), I still appreciate any further comments/feedback from the community.

[1] [https://trac.railml.org/ticket/373]

Thank you very much and 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: Stopping Place use cases
Next Topic: Extension suggestion for <upTime>
Goto Forum:
  


Current Time: Thu Aug 06 09:59:14 CEST 2020