Home » railML newsgroups » railML.infrastructure » NetRelation inconsistency for specific topology (NetRelations and NetElements problem)
NetRelation inconsistency for specific topology [message #2222] Fri, 12 July 2019 18:24 Go to next message
Fabiana Diotallevi is currently offline  Fabiana Diotallevi
Messages: 21
Registered: October 2018
Junior Member
Dear all,

the topology shown in the image attached (but it is not the only case!), seems to bring to an inconsistency in the netRelation definition.

/forum/index.php?t=getfile&id=50&private=0
In particular, if we consider the netRelation joining netElements ne_02 and ne_03 (upper and lower central tracks), both of the following relations could be exported:

<netRelation id="nr_0203" positionOnA="0" positionOnB="0" navigability="None">
<elementA ref="ne_02"/>
<elementB ref="ne_03"/>
</netRelation>

<netRelation id="nr_0203" positionOnA="1" positionOnB="1" navigability="None">
<elementA ref="ne_02"/>
<elementB ref="ne_03"/>
</netRelation>

There is no way to decide which one is the preferred one, and I can't export both of them because they have the same id and railML does not allow for a duplicate.

Is there a way to solve this problem?

Thanks,

f.
Re: NetRelation inconsistency for specific topology [message #2225 is a reply to message #2222] Fri, 19 July 2019 07:47 Go to previous messageGo to next message
Jörg von Lingen is currently offline  Jörg von Lingen
Messages: 86
Registered: March 2016
Member
Dear Fabiana,

I would suggest to collect netRelations always seen from connecting point clockwise. In your case you would get

<netRelation id="nr_0203" positionOnA="0" positionOnB="0" navigability="None">
<elementA ref="ne_02"/>
<elementB ref="ne_03"/>
</netRelation>

<netRelation id="nr_0302" positionOnA="1" positionOnB="1" navigability="None">
<elementA ref="ne_03"/>
<elementB ref="ne_02"/>
</netRelation>

Regards,
Jörg von Lingen - Interlocking Coordinator
Fabiana Diotallevi wrote on 12.07.2019 18:24:
> <netRelation id="nr_0203" positionOnA="0" positionOnB="0"
> navigability="None">
> <elementA ref="ne_02"/>
> <elementB ref="ne_03"/>
> </netRelation>
>
> <netRelation id="nr_0203" positionOnA="1" positionOnB="1"
> navigability="None">
> <elementA ref="ne_02"/>
> <elementB ref="ne_03"/>
> </netRelation>
Re: NetRelation inconsistency for specific topology [message #2232 is a reply to message #2222] Mon, 26 August 2019 13:06 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear Fabiana,

Am 12.07.2019 um 18:24 schrieb Fabiana Diotallevi:
> [...]
> In particular, if we consider the netRelation joining
> netElements ne_02 and ne_03 (upper and lower central
> tracks), both of the following relations could be exported:
>
> <netRelation id="nr_0203" positionOnA="0" positionOnB="0"
> navigability="None">
>                    <elementA ref="ne_02"/>
>                    <elementB ref="ne_03"/>
> </netRelation>
>
> <netRelation id="nr_0203" positionOnA="1" positionOnB="1"
> navigability="None">
>                    <elementA ref="ne_02"/>
>                    <elementB ref="ne_03"/>
> </netRelation>
>
> There is no way to decide which  one is the preferred one,
> and I can't export both of them because they have the same
> id and railML does not allow for a duplicate.
>
> Is there a way to solve this problem?

Yes, there is a way how to solve this problem:

In railML, IDs of elements must be unique (otherwise the parser will
throw an error). Further, an ID must not be used to "carry" information.
The ID must only be used for file internal identification (and
referencing). Thus, the ID "aqwzdq278fcas" is an even better ID than
"nr_0203". However, for purpose of understanding, the Simple Example
uses "readable" ID, but the used ID pattern is not mandatory. So, if I
programmed your exporting interface, I would take IDs based on
incrementing numbers (like a counter). Thus, although both netRelations
would connect the same netElements, they would have different IDs (e.g.
"e316" and "e317").

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: NetRelation inconsistency for specific topology [message #2250 is a reply to message #2232] Tue, 17 September 2019 10:31 Go to previous message
Fabiana Diotallevi is currently offline  Fabiana Diotallevi
Messages: 21
Registered: October 2018
Junior Member
Dear Jörg and Christian,

thank you very much for your feedback, the point is clear.
Since we need to export netElements and netRelations Ids from the drawing, we need a rule to automatically assign the Ids. At the same time, for sake of clarity, these Ids have to be "readable" for the user, in order to easily check the correctness of the exported xml file.


After some thoughts on this topic we have internally decided to define the rule that assigns the netRelation Id as follows:

nr_<ne1>_<ne2>_<connectingId>

where <ne1> and <ne2> are the ids of the involved netElements, while <connectingId> id the id of the connecting entity (switch/joint ...).

Therefore, the snippet of the exported railML file related to the attached figure shall be:

<netRelation id="nr_0203_swi01" positionOnA="0" positionOnB="0" navigability="None">
<elementA ref="ne_02"/>
<elementB ref="ne_03"/>
</netRelation>

<netRelation id="nr_0203_swi02" positionOnA="1" positionOnB="1" navigability="None">
<elementA ref="ne_02"/>
<elementB ref="ne_03"/>
</netRelation>


Hope this solution can help also other community members.

f.
Previous Topic: Proposed Semantic Constraint for <speedChange> in railML 2.x
Next Topic: [railML 3.2] extending the <speedProfile> element
Goto Forum:
  


Current Time: Thu Mar 28 17:41:37 CET 2024