railML2: trackRef@sequence [message #2157] |
Tue, 05 March 2019 10:48 |
Torben Brand
Messages: 158 Registered: March 2016
|
Senior Member |
|
|
Does anyone use trackRef@sequence?
https://wiki.railml.org/index.php?title=IS:trackRef_propEqui pment
We have a use case where we plan to have a macro model with only the main track forming the network. To indicate the track numbers in ocps we add topology unconnected tracks. The tracks are all connected to the <ocp> through crossSection@ocpRef and listed in ocp/propEquipment/trackRef@ref. Now it would be useful to be able to indicate the order of the parallel tracks in relation to each other. I thought of using trackRef@sequence here. But the wiki definition is to vague for this use case of ordering the tracks:
If no sequence is provided, the sequence of the referenced tracks shall be assumed as "arbitrary" or "undefined". In no case the sequence of the XML elements in the XML file shall matter.
Either all or none of the <trackRef> elements in the current <propEquipment> element shall carry sequence attributes.
The referenced track with the lowest sequence value is interpreted as the first element of the current <propEquipment>.
Each sequence value shall only be used once within the current <propEquipment>.
I suggest to add the following definition sentence to the existing definition in the wiki of trackRef@sequence:
"For parallel tracks the order is from right to left as seen in track direction of the main track from lowest to highest @sequence value."
Illustration:
|--track@type="secondary" @name="4" --- sequence:3 --->
|--------track@type="main" @name="2" ---------- sequence:2 ---------------------->
|--track@type="secondary" @name="1" --- sequence:1 --->
[Updated on: Tue, 05 March 2019 10:49] Report message to a moderator
|
|
|
Re: [railML2] trackRef@sequence [message #2161 is a reply to message #2157] |
Wed, 27 March 2019 07:55 |
christian.rahmig
Messages: 436 Registered: January 2016
|
Senior Member |
|
|
Dear Torben,
your question adresses the order of track references in an OCP.
Am 05.03.2019 um 10:48 schrieb Torben Brand:
> Does anyone use trackRef@sequence?
> https://wiki.railml.org/index.php?title=IS:trackRef_propEqui pment
>
> We have a use case where we plan to have a macro model with
> only the main track forming the network. To indicate the
> track numbers in ocps we add topology unconnected tracks.
> The tracks are all connected to the <ocp> through
> crossSection@ocpRef and listed in
> ocp/propEquipment/trackRef@ref. Now it would be useful to be
> able to indicate the order of the parallel tracks in
> relation to each other. I thought of using trackRef@sequence
> here. But the wiki definition is to vague for this use case
> of ordering the tracks:
>
> If no sequence is provided, the sequence of the referenced
> tracks shall be assumed as "arbitrary" or "undefined". In no
> case the sequence of the XML elements in the XML file shall
> matter. Either all or none of the <trackRef> elements in the current
> <propEquipment> element shall carry sequence attributes. The referenced
> track with the lowest sequence value is
> interpreted as the first element of the current
> <propEquipment>. Each sequence value shall only be used once within the
> current <propEquipment>.
>
> I suggest to add the definition to the wiki of
> trackRef@sequence:
> "For parallel tracks the order is from right to left as seen
> in track direction of the main track from lowest to highest
> @sequence value."
>
> Illustration:
>
> |--track@type="secondary" @name="4" --- sequence:3
> --->
> |--------track@type="main" @name="2" ---------- sequence:2
> ---------------------->
> |--track@type="secondary" @name="1" --- sequence:1
> --->
I agree with you that we should extend the description in the wiki in
order to make better use of the sequence attribute.
What does the community think about Torben's proposal?
I have an alternative suggestion for the order of tracks:
We could also define an order starting always from the operational
center of the OCP, e.g. the side where the station building is standing
(in case there is a station building). This means, that the track
sequence number increases the farer the track is away from the OCP
center. Tbd: how about OCP where there are tracks on both sides of the
center point?
The advantage of this alternative solution is that it does not depend on
the orientation of the main track. Imagine the situation that there are
two main tracks (one for each direction) are going through the OCP and
they are oriented in different directions. How to solve this with your
approach, Torben?
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: [railML2] trackRef@sequence [message #2169 is a reply to message #2162] |
Tue, 09 April 2019 22:09 |
christian.rahmig
Messages: 436 Registered: January 2016
|
Senior Member |
|
|
Dear Torben,
Am 27.03.2019 um 13:30 schrieb Torben Brand:
> [...]
>
> Thank you again for your valuable critical thinking.
> Your approach is much closer to reality. In fact this is the track number
> rule in norway for single track lines.
>
> But your suggestion would require that the new attribute
> crossSection@ocpCenterSide is set. This is not always the case.
Why not thinking it the other way around: you can derive the value of
<crossSection>@ocpCenterSide from the sequence numbers of all the tracks?
> For your suggestion with starting the sequence at the ocp (or main track
> for that manner) and with tracks on both sides of the operational center of
> the ocp we would need negative numbers for the other side of the reference.
> Unfortunately the attribute is of type xs:positiveInteger.
The type of the attribute <ocp><propEquipment><trackRef>@sequence could
be changed from xs:positiveInteger into xs:integer without loosing
backwards compatibility. Therefore, if there is a need for it, railML
2.5 could have this change included.
We alternative
> could group the sequence to their relative position to the reference (ocp
> or main reference track). For instance:
> - 0-99 left of the reference on line with the operational center of the ocp
> or crossSection of the reference main track
> - 100-199 right of the reference on line with the operational center of the
> ocp or crossSection of the reference main track
> - 200-299 left of the reference in front of operational center of the ocp
> or crossSection of the reference main track
> - 300-399 right of the reference in front of operational center of the ocp
> or crossSection of the reference main track
> - 400-499 right of the reference behind operational center of the ocp or
> crossSection of the reference main track
> - 500-599 right of the reference behind operational center of the ocp or
> crossSection of the reference main track
>
> With this we also could map shunting tracks the are in the ocp and in the
> same relative position as the secondary tracks but but with a higher
> kilometration.
This approach seems to be a more complex one...
However, what does the rest of the community think about this proposal?
> As the ocp has no direction, how do you define the left/right side of the
> ocp? Here you need to either use track direction or maybe increasing
> mileage direction. I would prefer track direction.
And I would prefer the direction of increasing mileage :-)
Any other opinions from the community?
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
|
|
|