New extention element "nor:visualisationElement". [message #1713] |
Wed, 28 February 2018 15:34 |
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 |
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 |
Jonathan Hecht
Messages: 2 Registered: December 2017
|
Junior Member |
|
|
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. 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 |
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 #1738 is a reply to message #1737] |
Wed, 21 March 2018 16:15 |
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 |
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 |
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
|
|
|
|
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 |
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 |
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
|
|
|