Home » railML newsgroups » railML.infrastructure » New extention element "nor:visualisationElement". (New extention element "nor:visualisationElement".)
New extention element "nor:visualisationElement". [message #1713] Wed, 28 February 2018 15:34 Go to next message
Torben Brand is currently offline  Torben Brand
Messages: 161
Registered: March 2016
Senior Member
To be able to fullfill the use case capacity planning we need to be able to visualise schematic track plans. Currently we use the depricated visualisation scheme in railML2.3nor. The scheme can allocate screen coordinates on extisting elements. But this is missing a independent visualisation element for elements that are not able to be touched "in real life". For instance to draw a "kink" aka. "picture element" to bend the schematic track. This usually after a track branches out from switch and then is bent to follow the mother track in parralel. The new element <nor:visualisationElements> with sub-element <nor:visualisationElement> will have no function but to place a screen coordinate on a defined pos on a defined track. The element is optional. If the element is used, the attribute pos is mandatory, code, name and description is optional. We suggest to place the new element under <track>.
<infrastructure>
 <track>
  <nor:visualisationElements>
   <nor:visualisationElement pos="integer" code="string" name="string" description="string" >

The purpose of such an element is to provide coordinates to layout the infrastructure at a given position (via absPos/relPos attributes). In some models only a few "main" elements like switches or crossings deliver usable layout coordinates. If you want to model a side track, you will have a problem to obtain a satisfying infrastructure layout. There are several discussions regarding the infrastructure visualization. Since 2.1 the <infrastructureVisualization>-container is marked as deprecated in the wiki, but is still usable according to the schema and is indeed used in the railML2.3nor extension. Therefor we would like to  use the <infrastructureVisualization>-container to refer to a <trackElementVis>-Element which assigns layout coordinates to a <nor:visualisationElement>.
Re: New extention element "nor:visualisationElement". [message #1733 is a reply to message #1713] Tue, 20 March 2018 15:35 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 447
Registered: January 2016
Senior Member
Dear Torben,

the subject of screen coordinates is essential to the use case
"Schematic Track Plan" and thus will be solved with railML 3.1 for sure.

I read your proposed solution for railML 2.3 NOR several and I came to
the conclusion that for railML 2.x there could be a simpler solution:

Instead of "re-animating" the visualization scheme, I suggest to
introduce a new element <screenCoord> at the same level like <geoCoord>.
<screenCoord> shall have attributes @x, @y (mandatory) and @z (optional)
defining a pixel position. A small example may look like this:

<levelCrossing id="lcr01" pos="123.45">
<geoCoord coord="52.26125 10.58776" epsgCode="4326"/>
<screenCoord x="250" y="550"/>
</levelCrossing>

What do you think about that proposal? Any feedback is appreciated...

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


Am 28.02.2018 um 15:34 schrieb Torben Brand:
> To be able to fullfill the use case capacity planning we
> need to be able to visualise schematic track plans.
> Currently we use the depricated visualisation scheme in
> railML2.3nor. The scheme can allocate screen coordinates on
> extisting elements. But this is missing a independent
> visualisation element for elements that are not able to be
> touched "in real life". For instance to draw a "kink" aka.
> "picture element" to bend the schematic track. This usually
> after a track branches out from switch and then is bent to
> follow the mother track in parralel. The new element
> <nor:visualisationElements> with sub-element <nor:visualisationElement>
> will have no function but to
> place a screen coordinate on a defined pos on a defined
> track. The element is optional. If the element is used, the
> attribute pos is mandatory, code, name and description is
> optional. We suggest to place the new element under <track>.
>
>
> <infrastructure>
> <track>
> <nor:visualisationElements>
> <nor:visualisationElement pos="integer" code="string"
> name="string" description="string" >
> The purpose of such an element is to provide coordinates to
> layout the infrastructure at a given position (via
> absPos/relPos attributes). In some models only a few "main"
> elements like switches or crossings deliver usable layout
> coordinates. If you want to model a side track, you will
> have a problem to obtain a satisfying infrastructure layout.
> There are several discussions regarding the infrastructure
> visualization. Since 2.1 the
> <infrastructureVisualization>-container is marked as
> deprecated in the wiki, but is still usable according to the
> schema and is indeed used in the railML2.3nor extension.
> Therefor we would like to use the
> <infrastructureVisualization>-container to refer to a
> <trackElementVis>-Element which assigns layout coordinates
> to a <nor:visualisationElement>.
>


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: New extention element "nor:visualisationElement". [message #1735 is a reply to message #1733] Wed, 21 March 2018 14:18 Go to previous messageGo to next message
Jonathan Hecht is currently offline  Jonathan Hecht
Messages: 2
Registered: December 2017
Junior Member
Dear Christian,

if I may join the discussion. Smile

"Instead of "re-animating" the visualization scheme, I suggest to
introduce a new element <screenCoord> at the same level like <geoCoord>. "

Would be nice to have such an element, so we do not have to use the deprecated visualization scheme in railML 2.x.

But on top we need a separate element for this use case, which also can have absolute and relative positions and is independent from another element. It is also not able to be touched "in real life". So combined:
<nor:visualisationElements>
   <nor:visualisationElement pos="integer" code="string" name="string" description="string" >
     <screenCoord x="250" y="550"/>
   </nor:visualisationElement>
</nor:visualisationElements>


Best regards
Jonathan

[Updated on: Wed, 21 March 2018 14:25]

Report message to a moderator

Re: New extention element "nor:visualisationElement". [message #1736 is a reply to message #1735] Wed, 21 March 2018 15:20 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 447
Registered: January 2016
Senior Member
Dear Jonathan,

of course, you are very much welcome to join the discussion! :)

Sorry, but I do not fully understand your request. If you want to give
screen coordinates to an element that cannot be touched in real life,
just use the <geoMapping> track element: it can be placed with absolute
and relative coordinates, and it is independent from any physical
infrastructure component. By using the attributes @name and @description
you may place further information.

So, just adapting my previous example, it would look like this:

<geoMapping id="geo01" pos="123.45" absPos="4567.89" name="string"
description="string">
<geoCoord coord="52.26125 10.58776" epsgCode="4326"/>
<screenCoord x="250" y="550"/>
</geoMapping>

What are you missing?

Best regards
Christian

Am 21.03.2018 um 14:18 schrieb Jonathan Hecht:
> Dear Christian,
>
> if I may join the discussion. :)
> "Instead of "re-animating" the visualization scheme, I
> suggest to
> introduce a new element <screenCoord> at the same level like
> <geoCoord>. "
> Would be nice to have such an element, so we do not have to
> use the deprecated visualization scheme in railML 2.x.
> But on top we need a separate element for this use case,
> which also can have absolute and relative positions and is
> independent from another element. So combined it would be
> something like:
>
> <nor:visualisationElements>
> <nor:visualisationElement pos="integer" code="string"
> name="string" description="string" >
> <screenCoord x="250" y="550"/>
> </nor:visualisationElement>
> </nor:visualisationElements>
>
>
> Best regards
> Jonathan


--
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: New extention element "nor:visualisationElement". [message #1737 is a reply to message #1736] Wed, 21 March 2018 16:00 Go to previous messageGo to next message
Jonathan Hecht is currently offline  Jonathan Hecht
Messages: 2
Registered: December 2017
Junior Member
Sorry, I've forgotten about this element or to make use of it in this case. So you are right. We could use it in combination with the new "screenCoord"-element then. Although we would not have any "geographic coordinates" for it.

Is the <geoCoord>-child required for a <geoMapping>-element? Thanks.

[Updated on: Wed, 21 March 2018 16:02]

Report message to a moderator

Re: New extention element "nor:visualisationElement". [message #1738 is a reply to message #1737] Wed, 21 March 2018 16:15 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 447
Registered: January 2016
Senior Member
Am 21.03.2018 um 16:00 schrieb Jonathan Hecht:
> [...]
> Is the <geoCoord>-child required for a <geoMapping>-element?

No, the <geoCoord> child element is always optional and does not have to
be provided.

--
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: New extention element "nor:visualisationElement". [message #1739 is a reply to message #1733] Wed, 21 March 2018 16:18 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 447
Registered: January 2016
Senior Member
Dear all,

I updated the Trac ticket #104 [1] about the railML infrastructure
visualization model according to the discussion taking place here.

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

Best regards
Christian

Am 20.03.2018 um 15:35 schrieb Christian Rahmig:
> Dear Torben,
>
> the subject of screen coordinates is essential to the use case
> "Schematic Track Plan" and thus will be solved with railML 3.1 for sure.
>
> I read your proposed solution for railML 2.3 NOR several and I came to
> the conclusion that for railML 2.x there could be a simpler solution:
>
> Instead of "re-animating" the visualization scheme, I suggest to
> introduce a new element <screenCoord> at the same level like <geoCoord>.
> <screenCoord> shall have attributes @x, @y (mandatory) and @z (optional)
> defining a pixel position. A small example may look like this:
>
> <levelCrossing id="lcr01" pos="123.45">
> <geoCoord coord="52.26125 10.58776" epsgCode="4326"/>
> <screenCoord x="250" y="550"/>
> </levelCrossing>
>
> What do you think about that proposal? Any feedback is appreciated...
>
> Best regards
> Christian
>


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: New extention element "nor:visualisationElement". [message #1781 is a reply to message #1739] Mon, 30 April 2018 17:06 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 447
Registered: January 2016
Senior Member
Dear all,

based on the feedback from the 33rd railML Conference in Berlin two
weeks ago, I suggest to implement the proposed solution from Trac ticket
#104 [1] with railML 2.4, ok?

Best regards
Christian

Am 21.03.2018 um 16:18 schrieb Christian Rahmig:
> Dear all,
>
> I updated the Trac ticket #104 [1] about the railML infrastructure
> visualization model according to the discussion taking place here.
>
> [1] https://trac.railml.org/ticket/104
>
> Best regards
> Christian
>
> Am 20.03.2018 um 15:35 schrieb Christian Rahmig:
>> Dear Torben,
>>
>> the subject of screen coordinates is essential to the use case
>> "Schematic Track Plan" and thus will be solved with railML 3.1 for sure.
>>
>> I read your proposed solution for railML 2.3 NOR several and I came to
>> the conclusion that for railML 2.x there could be a simpler solution:
>>
>> Instead of "re-animating" the visualization scheme, I suggest to
>> introduce a new element <screenCoord> at the same level like <geoCoord>.
>> <screenCoord> shall have attributes @x, @y (mandatory) and @z (optional)
>> defining a pixel position. A small example may look like this:
>>
>> <levelCrossing id="lcr01" pos="123.45">
>> <geoCoord coord="52.26125 10.58776" epsgCode="4326"/>
>> <screenCoord x="250" y="550"/>
>> </levelCrossing>
>>
>> What do you think about that proposal? Any feedback is appreciated...
>>
>> 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
Additional questions for screen visualisation (Re: New extention element "nor:visualisationElement".) [message #1784 is a reply to message #1781] Thu, 03 May 2018 01:22 Go to previous messageGo to next message
Tobias Bregulla is currently offline  Tobias Bregulla
Messages: 20
Registered: June 2017
Junior Member
Dear Christian, dear railML community!

We intend to support screen coordinates in our software in future
version too. Therefore we would like to have a possibility to store them
too. From our side it is not finally decided if we will use it on short
term (means: railML 2.3 with own extensions or railML 2.4) or mid term
(means: railML 3.x). Therefore we'll be more neutral in the current
decision of railML.org.

Regarding the proposed solution of railML's ticket #104 (see below) we
see some more additional questions to be answered before a new modelling:
- What about a percentage value for screen coordinates? This would
give opportunities to fit to very different screen resolutions from
mobile phones (portrait) up to Retina displays (landscape) like we are
supporting in our VIA infrastructure database viewer project.
- What about the adressing of more than one screen and the
cross-screen adressing?
- What about the adressing of linear and areal elements (maybe with
out of right angles)?

Maybe a "re-animating" the visualization scheme for railML 2.4 and more
complete solution with longer development time for railML 2.5 and/or
railML 3.1 could be a more hassle free idea.

Best regards,

Tobias Bregulla and the whole Bahnkonzept team

Am 30.04.2018 um 17:06 schrieb Christian Rahmig:
> Dear all,
>
> based on the feedback from the 33rd railML Conference in Berlin two
> weeks ago, I suggest to implement the proposed solution from Trac ticket
> #104 [1] with railML 2.4, ok?
>
> Best regards
> Christian
>
>> Am 20.03.2018 um 15:35 schrieb Christian Rahmig:
>>> Dear Torben,
>>>
>>> the subject of screen coordinates is essential to the use case
>>> "Schematic Track Plan" and thus will be solved with railML 3.1 for sure.
>>>
>>> I read your proposed solution for railML 2.3 NOR several and I came to
>>> the conclusion that for railML 2.x there could be a simpler solution:
>>>
>>> Instead of "re-animating" the visualization scheme, I suggest to
>>> introduce a new element <screenCoord> at the same level like <geoCoord>.
>>> <screenCoord> shall have attributes @x, @y (mandatory) and @z (optional)
>>> defining a pixel position. A small example may look like this:
>>>
>>> <levelCrossing id="lcr01" pos="123.45">
>>>   <geoCoord coord="52.26125 10.58776" epsgCode="4326"/>
>>>   <screenCoord x="250" y="550"/>
>>> </levelCrossing>
>>>
>>> What do you think about that proposal? Any feedback is appreciated...
>>>
>>> Best regards
>>> Christian
Re: Additional questions for screen visualisation (Re: New extention element "nor:visualisationElement".) [message #1809 is a reply to message #1784] Tue, 29 May 2018 18:32 Go to previous messageGo to next message
Thomas Nygreen JBD is currently offline  Thomas Nygreen JBD
Messages: 68
Registered: February 2017
Member
I support Christian Rahmig's suggestion to use the geoMapping element rather than create a new one.

Regarding the proposed screenCoord element, I am a bit ambivalent. If implemented, it should be possible to have more than one screenCoord element, with a @positioningSystemRef, as proposed for railML3.

I disagree with Tobias Bregulla regarding the need for percentage or multi-screen coordinates. Placement and scaling should be handled by the rendering software. The point is simply to place the elements on a two-dimensional grid.


Best regards,
Thomas Nygreen
Railway capacity engineer
Jernbanedirektoratet
Re: Additional questions for screen visualisation (Re: New extention element "nor:visualisationElement".) [message #1824 is a reply to message #1784] Mon, 04 June 2018 13:43 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 447
Registered: January 2016
Senior Member
Dear all,

following the proposal from Tobias...

Am 03.05.2018 um 01:22 schrieb Tobias Bregulla:
> [...]
> Maybe a "re-animating" the visualization scheme for railML 2.4 and more
> complete solution with longer development time for railML 2.5 and/or
> railML 3.1 could be a more hassle free idea.

.... and discussions e.g. in the railML use case working group "Schematic
Track PLan", we came to the conclusion to withdraw the "DEPRECATED" flag
from the infrastructure visualizeation scheme. This shall be done with
railML 2.4 and it shall remain valid until a final solution has been
found for railML 3.x. Do you agree with this strategy?

More details on the whole issue can be found in Trac ticket #104 [1].

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

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
Previous Topic: [railML 3.1] UML mit xsd::any
Next Topic: suggestion for improved use of infraAttrGroups
Goto Forum:
  


Current Time: Sat Jul 20 09:04:25 CEST 2024