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: 156
Registered: March 2016
Senior 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: 436
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: 156
Registered: March 2016
Senior 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 messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
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
Re: [railML2] Suggested definition of <ocpVis> [message #2741 is a reply to message #2354] Mon, 31 May 2021 11:45 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear all,

as there has been no further comments from the community for more than one year, I followed Torben's suggestion and implemented the following:
* add new element <objectVis> for visualizing objects that are not located on a line or a track, e.g. OCPs or controllers
* deprecate element <ocpVis> that has been used for visualizing OCPs before

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: [railMl2] Proposal for new attribute @switchable in <baliseGroup> and wiki refinement
Next Topic: [railML3] Improvement for railML element „etcsLevelTransition"
Goto Forum:
  


Current Time: Fri Mar 29 01:37:01 CET 2024