Home » railML newsgroups » railml.infrastructure » the use of @dir in railML. (@dir)
the use of @dir in railML. [message #1959] Wed, 12 September 2018 14:57 Go to next message
Torben Brand is currently offline  Torben Brand
Messages: 58
Registered: March 2016
Member
I would like to address the use of @dir in railML.
The direction of the objects on the track is always given in railML through the track direction (from the <trackBegin> to the <trackEnd> or seen in increasing relative position values)
@dir denotes the validity of the objects as seen from the direction of travel by the train. Or as it says similar in the gradientChange wiki: "dir: This defines the validity of gradientChange along the track."
Suggestion for a more clear term in railML3 that creates less confusion would be @validDir (or something similar).

Direction restrictions come in three pre-set levels in railML:
"lax" with the enumeration values "up","down","unknown","none","both"
"delimited" with the enumeration values "up","down","unknown"
"strict" with the enumeration values "up" or "down"

The values are defined to (taken from wiki for gradientChange):

Possible values are:
• none: gradientChange has no direction restriction.
• up: This denotes the direction from the <trackBegin> to the <trackEnd> (increasing relative position values).
• down: This goes opposite to up (decreasing relative position values).
• both: gradientChange is valid in both directions.
• unknown: gradientChange is restricted to a certain direction, but this direction is not known.

First having the value "none" and "both" make no sense. This as they both cover the same thing (glass is half full or half empty)

The wiki pages describing @dir for gradientChange, trackCircuitBorder and trainDetector (possible other pages that use @dir, I have not checked) are inconsistent.

The possible values listed are the 5 lax values.
Under constraint it is referenced to: "dir: xs:string, generic type for more constrained direction statements: enumeration up, down, unknown; derived from tLaxDirection; optional "
tLaxDirection are the 5 listed values, but the values listed in constraint are the tDelimitedDirection values.
In the XSD the tStrictDirection values are used for gradientChange and tDelimitedDirection values are used for trainDetector and trackCircuitBorder. So only the values "up" and "down" (and "unknown") are allowed under @dir.
As the XSD is the master I suggest to edit the wiki pages to the following:

Possible values are:
• up: This denotes the direction from the <trackBegin> to the <trackEnd> (increasing relative position values).
• down: This goes opposite to up (decreasing relative position values).
Setting no @dir attribute defines that the object has no direction restraint. This corresponds to the lax values "none" or "both". Modelling of "unknown" is currently not possible for @dir in railML2.

Constraint
dir: xs:string, generic type for more constrained direction statements: enumeration up, down; derived from tStrictDirection; optional 

gradientChange: https://wiki.railml.org/index.php?title=IS:gradientChange
trackCircuitBorder: https://wiki.railml.org/index.php?title=IS:trackCircuitBorde r
trainDetector: https://wiki.railml.org/index.php?title=IS:trainDetector

[Updated on: Wed, 12 September 2018 15:03]

Report message to a moderator

directions in railML 3 [message #1967 is a reply to message #1959] Mon, 17 September 2018 12:01 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 163
Registered: January 2016
Senior Member
Dear Torben,

let me cut your posting in several small pieces to be answered...

Am 12.09.2018 um 14:57 schrieb Torben Brand:
> [...]
> @dir denotes the validity of the objects as seen from the
> direction of travel by the train. Or as it says similar in
> the gradientChange wiki: "dir: This defines the validity
> of gradientChange along the track."
> Suggestion for a more clear term in railML3 that creates
> less confusion would be @validDir (or something similar).

In railML 3, we follow the RailTopoModel that already defines the
direction attribute @applicationDirection in classes LinearLocation and
SpotLocation.

@all: Please let us know if you would prefer another name for this
attribute.

Thank you very much and best regards
Christian Rahmig

--
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
Values of attribute @dir [message #1968 is a reply to message #1959] Mon, 17 September 2018 12:15 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 163
Registered: January 2016
Senior Member
Dear Torben,

here comes answer part 2...

Am 12.09.2018 um 14:57 schrieb Torben Brand:
> [...]
> @dir denotes the validity of the objects as seen from the
> direction of travel by the train. Or as it says similar in
> the gradientChange wiki: "dir: This defines the validity
> of gradientChange along the track."
> [...]
>
> Possible values are:
> • none: gradientChange has no direction restriction.
> • up: This denotes the direction from
> the <trackBegin> to the <trackEnd> (increasing
> relative position values).
> • down: This goes opposite to up (decreasing
> relative position values).
> • both: gradientChange is valid in both directions.
> • unknown: gradientChange is restricted to a certain
> direction, but this direction is not known.
>
> First having the value "none" and "both" make no sense. This
> as they both cover the same thing (glass is half full or
> half empty)

I think you are right. The value "none" does not make much sense since
all possibilities of direction validity are covered by the other values:
* up (for elements being valid in up direction)
* down (for elements being valid in down direction)
* both (for elements being valid in both directions)

And if an information is unknown, you may leave this optional attribute
empty.

So, we may put it on the agenda for a next railML version? By the way,
in railML 3, the new attribute @applicationDir has been implemented
exactly that way - with only three values. Instead of "up" and "down"
the terms "normal" and "reverse" are being used, but the meaning is the
same.

@all: Do you have any examples where you use direction enumeration
values "none" or "unknown"?

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
Previous Topic: [railML3.1|Simple Example] Errors
Goto Forum:
  


Current Time: Thu Sep 20 23:51:21 CEST 2018