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: 78
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 message
christian.rahmig is currently offline  christian.rahmig
Messages: 244
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
Previous Topic: [railML 3.2] extending the <balise> element
Next Topic: Suggested extension for operating rules
Goto Forum:
  


Current Time: Sat Dec 07 10:47:19 CET 2019