Forum: railML.infrastructure » Suggested definition of <ocpVis>

Home » railML newsgroups » railML.infrastructure » Suggested definition of <ocpVis> (<infrastructureVisualisation>)

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

Tue, 03 December 2019 12:02

Torben Brand
Messages: 162
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>.

Report message to a moderator

Fri, 06 December 2019 19:59

christian.rahmig
Messages: 460
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

Report message to a moderator

Wed, 26 February 2020 16:28

Torben Brand
Messages: 162
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.

Report message to a moderator

Re: [railML2] Suggested definition of <ocpVis> [message #2354 is a reply to message #2286]

Wed, 26 February 2020 20:54

christian.rahmig
Messages: 460
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

Report message to a moderator

Re: [railML2] Suggested definition of <ocpVis> [message #2741 is a reply to message #2354]

Mon, 31 May 2021 11:45

christian.rahmig
Messages: 460
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

Report message to a moderator

Previous Topic:	[railMl2] Proposal for new attribute @switchable in <baliseGroup> and wiki refinement
Next Topic:	railML 2.3 infrastructure extension proposal line sections

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Wed Sep 11 11:59:06 CEST 2024