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: 179
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 messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 179
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
Re: the use of @dir in railML. [message #1985 is a reply to message #1959] Mon, 08 October 2018 15:14 Go to previous messageGo to next message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 16
Registered: February 2017
Junior Member
I would like to look a bit broader at the use and interpretation of the @dir attribute. As Torben points out, the documentation is lacking, and in some cases incorrect. Currently this attribute is not documented in the wiki or XSD at all, apart from the quite uninformative "This defines the validity of <element> along the track" and the restrictions described in more technical terms. The description that Torben mentions says "derived from tLaxDirection" because it is a description of the (badly named) tDelimitedDirection, and this type is indeed derived from tLaxDirection.

I agree that "none" and "both" are two sides to the same coin, and one of them can be removed. Regarding "unknown", there is according to the documentation a subtle difference between @dir="unknown" and a missing @dir: with "unknown" the element "is restricted to a certain direction, but this direction is not known", while with a missing @dir we do not know if there is any restriction at all (or in most cases we assume that there is not). However, I have yet not seen a real use case, and unless anyone else has, it can maybe also be removed.

Suggested change:
* Remove "unknown" and "none" from enumeration


There are 26 elements in the railML 2.3/2.4 infrastructure schema that support the dir attribute. Additionally there are two elements where this attribute is deprecated (crossSection and mileageChange), which I will disregard below. The elements can be divided into three categories: elements without extent, elements with extent and elements that describe a change that occurs at a given point.

The first group, elements without extent (i.e. without a @length) include: balise, border, derailer, signal, stopPost, trackCircuitBorder, trainDetector and trainProtectionElement. The interpretation of @dir for most of the physical elements in this group is quite simple: they apply only to trains in that direction. For trackCircuitBorder, however, a rail joint cannot be isolated in only one direction. For the more abstract border element, I am not quite sure about the purpose of @dir. The only one I can think of is that there could be borders that are placed differently in the two directions.

Suggested changes:
* DEPRECATE @dir for border and trackCircuitBorder
* Remove "both" from enumeration for derailer, signal and stopPost unless anyone has an example


The second group, the elements with an extent (i.e. with @length) include: brigde, levelCrossing, platformEdge, serviceSection, trackCondition and tunnel. This group is less simple. Using the same logic and definition as above would imply that a tunnel, bridge etc. with @dir="up" is "not there" if you drive in the "down" direction, and can be ignored by those trains. If tunnels that are invisible and without air resistance in one direction actually exist, please inform me! The only element in this group that can be interpreted in this fashion is trackCondition. For the remaining elements the intention may have been to specify that it is only allowed to drive through/along the element in one direction, but this would mean that @dir must be interpreted very differently for these elements. Furthermore, such a restriction would not be a property of this element, but of the track it is placed on or the signalling and interlocking system. Consequently I suggest to deprecate @dir for all these elements, except trackCondition.

Suggested changes:
* DEPRECATE @dir for brigde, levelCrossing, platformEdge, serviceSection (?) and tunnel


The last group, elements that describe a change, include: axleWeightChange, clearanceGaugeChange, electrificationChange, gaugeChange, gradientChange, operationModeChange, ownerChange, powerTransmissionChange, radiusChange, speedChange, trainProtectionChange and trainRadioChange. In these cases the general interpretation of @dir is quite simple: the specified change only applies when traversing the track in the given direction. The best known example is probably speedChange, where it is common knowledge that speed profiles my differ in the two directions. The detailed interpretation can however be tricky, as I will soon describe. Also, for some of these characteristics, it does not make much sense allowing different values in different directions. I suggest to deprecate the @dir attribute for most of these elements, as I do not know of applications where their properties can differ by direction. I welcome all examples to the contrary. For speed, train protection and train radio, there can obviously be some differences between directions, at least in exactly where the change happens. For gradients, there are use cases where the exact gradient at every point is unknown but the average or characteristic gradient between consecutive signals is known, and since signal placement may vary between directions, so will these averaged gradients (even if the track itself must have the same gradient in both directions).

Suggested changes:
* DEPRECATE @dir for axleWeightChange, clearanceGaugeChange, electrificationChange, gaugeChange, operationModeChange, ownerChange, powerTransmissionChange and radiusChange unless anyone has an example
* Only allow up/down for trainRadioChange


The remaining question for all change elements when @dir is used, is what part of the track the given values apply to. Let's start with a speedChange example without @dir:

<speedChange pos="0" vMax="40"/>
<speedChange pos="100" vMax="80"/>

This is simple to interpret as the following. Generally, the new values apply to the segment of the track between this element and the next in the direction of the track.

Pos     0                  100                   200
Track   |---------------------------------------------->
vMax    |        40         |          80   


Now, if we alter one direction, what should the @pos value of the element with @dir="down" be?

Pos     0                  100                   200
Track   |---------------------------------------------->
vMax -> |        60         |          80   
vMax <- |        40         |          80   


I cannot find any documentation answering that question. According to a very old thread on this forum, the intended use was like this:

<speedChange pos="0" dir="up" vMax="60"/>
<speedChange pos="0" dir="down" vMax="40"/>
<speedChange pos="100" vMax="80"/>

While, in my experience, and also mentioned in a later post in the same old forum thread, the common practice is to use @pos="100" on the @dir="down" element. I find the intended use to be more consistent: the given new values always apply to the segment of track between this change and the next change of the same type found in the direction of the track. The @dir attribute, if given, only affects which direction (of travel) the values apply to.

BUT, it is important what the common practice is. So unless I am mistaken about the current common practice, the definition would be: unless @dir="down" the given new values apply to the segment of track between this change and the next change of the same type found in the direction of the track. When @dir="down", the given new values apply to the segment of track between this change and the previous change of the same type.

Regardless of choice of definition, it should be the same for all change elements.

Suggested change:
* Document what part of the track the new values apply to when using the @dir attribute

[Updated on: Mon, 08 October 2018 15:16]

Report message to a moderator

Re: the use of @dir in railML. [message #1990 is a reply to message #1985] Fri, 19 October 2018 10:34 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 253
Registered: August 2008
Senior Member
Dear Thomas,

I found your composition on @dir very refreshing and fundamental and welcome the detailed work. Hopefully, it was not for nothing... ;-)

In many aspects I see a kind of rather philosophical background in it which we also often had and have in <timetable> discussions: Whether to make railML rather "flexible" or rather "strong, exact".

To make it short: I don't have general objections against you suggestions. I also would welcome to make @dir more exact.

As often, there is unfortunately a "but":

> * DEPRECATE @dir for border and trackCircuitBorder

I can imagine borders which need a direction. As I mentioned earlier in a post with Torben about station limits, in Germany we have direction-dependant station limits. For instance, from the view of interlocking, for a train entering a station, the limit is the home signal (Einfahrsignal). For a train of the opposite direction, that leaves the station, the limit is the shunting-limit marker (Rangierhalttafel Ra10).

So, if a <border> can for instance encode the interlocking or operational station limits, we may need a @dir attribute.

---
Concerning <speedChange>s:

> BUT, it is important what the common practice is.

For many years, we use <speedChange> in the way you describe it, with @dir=up or =down dependant to the validity direction of speedProfiles:
- We always encode speedProfiles in the direction of (relative) mileage, means in order of raising @pos attributes, independent of the validity direction (of travel) of the speedChanges.
- In cases of a speedProfile is valid for the =down direction, our <speedChange>@speed value is valid from that @pos until the previous (!)(not next!) <speedChange>.
- The <speedChange>@dir never encodes the validity direction of the <speedProfile>. It only says in which direction (next or previous element) the @speed is valid. The <speedProfile> has its own direction an can be valid for both directions.
- This is documented in our own documentation of FBS-railML-interface, which is a kind of extension and concretion of the general Wiki.

> Suggested change:
> * Document what part of the track the new values apply to
> when using the @dir attribute

I can do it if Christian Rahmig agrees and/or if there will be no objections here.

---
> Suggested changes:
> * DEPRECATE @dir for brigde, levelCrossing, platformEdge,
> serviceSection (?) and tunnel

I think is is a misunderstanding:
The intention behind @dir was never to encode that the tunnel or bridge is not visible for the other direction.
The intention may have been:
<tunnel @pos=1234 @length=200 @dir=up> = a tunnel from km 1,234 to 1,434
<tunnel @pos=1234 @length=200 @dir=down> = a tunnel from km 1,034 to 1,234
This would fit in a certain way to the way <speedChanges> are to interpret from @dir.

However, I have no objections against killing this redundancy and deprecate @dir from brigdes, tunnels etc.

With best regards,
@Dir_k.
Re: the use of @dir in railML. [message #1991 is a reply to message #1990] Fri, 19 October 2018 16:42 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 179
Registered: January 2016
Senior Member
Dear Thomas, dear @Dir_k ;-)

Am 19.10.2018 um 10:34 schrieb Dirk Bräuer:
> I found your composition on @dir very refreshing and fundamental and welcome the detailed work. Hopefully, it was not for nothing... ;-)

I agree with Dirk: Thomas, your notes on the @dir topic are very
detailed and useful for further railML (2 and 3) development. Thank you!

> To make it short: I don't have general objections against you suggestions. I also would welcome to make @dir more exact.

I take your advice very serious for railML 3.1 implementation. The
railML 2 attribute @dir is named @applicationDirection in RTM and railML 3.

>> * DEPRECATE @dir for border and trackCircuitBorder
>
> I can imagine borders which need a direction. As I mentioned earlier in a post with Torben about station limits, in Germany we have direction-dependant station limits. For instance, from the view of interlocking, for a train entering a station, the limit is the home signal (Einfahrsignal). For a train of the opposite direction, that leaves the station, the limit is the shunting-limit marker (Rangierhalttafel Ra10).
>
> So, if a <border> can for instance encode the interlocking or operational station limits, we may need a @dir attribute.

And what about track circuit borders, where there is a track circuit
only on one side (like we have it in the Simple Example at signal 69A)?
The attribute @applicationDirection has been used there to define on
which side(s) of the track circuit border track circuits can be found.
Do you consider this being logical?

> Concerning <speedChange>s:
>
>> BUT, it is important what the common practice is.
>
> For many years, we use <speedChange> in the way you describe it, with @dir=up or =down dependant to the validity direction of speedProfiles:
> - We always encode speedProfiles in the direction of (relative) mileage, means in order of raising @pos attributes, independent of the validity direction (of travel) of the speedChanges.
> - In cases of a speedProfile is valid for the =down direction, our <speedChange>@speed value is valid from that @pos until the previous (!)(not next!) <speedChange>.
> - The <speedChange>@dir never encodes the validity direction of the <speedProfile>. It only says in which direction (next or previous element) the @speed is valid. The <speedProfile> has its own direction an can be valid for both directions.

In railML context, <speedChange> elements may have a direction while
<speedProfile> don't have this attribute. However, Dirk is right when he
says that <speedProfile> elements have a direction information, too. It
is given implicitly by the <speedChange> elements referencing this
<speedProfile>. So, if elements <speedChange>@dir=up and
<speedChange>@dir=down reference the same <speedProfile>, this
<speedProfile> is de-facto valid for both directions.

>> Suggested change:
>> * Document what part of the track the new values apply to
>> when using the @dir attribute
>
> I can do it if Christian Rahmig agrees and/or if there will be no objections here.

Absolutely no objections from my side! I am thankful for any
contribution. I suggest to do it on the discussion page of element
<speedChange> in the railML wiki
(https://wiki.railml.org/index.php?title=IS:speedChange). Once, we have
an agreement on the final solution, we may integrate it as "Best
Practice" on the main wiki page of <speedChange>.

>> Suggested changes:
>> * DEPRECATE @dir for brigde, levelCrossing, platformEdge,
>> serviceSection (?) and tunnel
>
> I think is is a misunderstanding:
> The intention behind @dir was never to encode that the tunnel or bridge is not visible for the other direction.
> The intention may have been:
> <tunnel @pos=1234 @length=200 @dir=up> = a tunnel from km 1,234 to 1,434
> <tunnel @pos=1234 @length=200 @dir=down> = a tunnel from km 1,034 to 1,234
> This would fit in a certain way to the way <speedChanges> are to interpret from @dir.

>
> However, I have no objections against killing this redundancy and deprecate @dir from brigdes, tunnels etc.

For final answering this question I would like to receive more feedback
from the community. Do we want to introduce a rule that says:
"infrastructure elements with length have to be defined always in
direction of the track orientation (increasing @pos)"? If there is a
majority supporting this approach, we may think about an implementation
(in railML 2.5?).

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
Re: the use of @dir in railML. [message #1995 is a reply to message #1959] Wed, 24 October 2018 15:17 Go to previous message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 16
Registered: February 2017
Junior Member
Dear Dirk, dear Christian,

Thank you for your kind words!

Quote:
In many aspects I see a kind of rather philosophical background in it which we also often had and have in <timetable> discussions: Whether to make railML rather "flexible" or rather "strong, exact".


My intention is to ensure that we know how to interpret a given railML file. I welcome flexibility in the use and purposes of railML, but not in interpretation. When I suggest to deprecate @dir for a lot of elements it is simply because I cannot find a good interpretation for it.

Quote:
The railML 2 attribute @dir is named @applicationDirection in RTM and railML 3.


Much better! However, this attribute will probably never be self-explanatory unless you use a stupidly long and complex name, so documentation will still be important ;)

Quote:
> * DEPRECATE @dir for border and trackCircuitBorder

I can imagine borders which need a direction. As I mentioned earlier in a post with Torben about station limits, in Germany we have direction-dependant station limits. For instance, from the view of interlocking, for a train entering a station, the limit is the home signal (Einfahrsignal). For a train of the opposite direction, that leaves the station, the limit is the shunting-limit marker (Rangierhalttafel Ra10).

So, if a <border> can for instance encode the interlocking or operational station limits, we may need a @dir attribute.


As station is a valid @type for <border>, and you describe a use case for @dir for that @type, we should keep @dir for <border>.

Quote:
And what about track circuit borders, where there is a track circuit
only on one side (like we have it in the Simple Example at signal 69A)?
The attribute @applicationDirection has been used there to define on
which side(s) of the track circuit border track circuits can be found.
Do you consider this being logical?


Short answer: no.

Longer answer:
* As a general rule, please do not use the same attribute name to mean very different things for different objects. Contrary to e.g. a signal, a track circuit border applies to trains running in both directions, even if there is a track circuit only on one side. For trains in one direction it marks where they are entering the track circuit section, and in the other direction it marks where they are leaving it.
* The need for information about the track circuits themselves should be solved by adding a trackCircuit element, not by abusing a vague attribute of <trackCircuitBorder>. If you really need to use an attribute, create a new one.
* In the railML2.3 version of the Simple Example, @dir is not used for the <trackCircuitBorder>s. (Instead it looks like you are using @insulatedRail="none", which to me makes no sense, but that is probably another discussion.)
* In case anyone argues that track circuits belong to interlocking: I disagree. They are physical objects (wired circuits), that are used by the interlocking to determine the current state, just like the interlocking also uses positions of switches and derailers.

Quote:
For many years, we use <speedChange> in the way you describe it, with @dir=up or =down dependant to the validity direction of speedProfiles:
- We always encode speedProfiles in the direction of (relative) mileage, means in order of raising @pos attributes, independent of the validity direction (of travel) of the speedChanges.
- In cases of a speedProfile is valid for the =down direction, our <speedChange>@speed value is valid from that @pos until the previous (!)(not next!) <speedChange>.
- The <speedChange>@dir never encodes the validity direction of the <speedProfile>. It only says in which direction (next or previous element) the @speed is valid. The <speedProfile> has its own direction an can be valid for both directions.
- This is documented in our own documentation of FBS-railML-interface, which is a kind of extension and concretion of the general Wiki.


From your description, it is not fully clear to me if you are referring to the way I described as the intended usage or the assumed common usage. It is probably my fault, as I did not write the railML code for the last one. So, just to be as clear as possible, using the same example:

Pos     0                  100                   200
Track   |---------------------------------------------->
vMax -> |        60         |          80   
vMax <- |        40         |          80   


The two alternatives for the first section (0100 m) in railML2.x are (differences in bold):

Alternative A (intended use, according to Susanne Wunsch in 2012):
<speedChange pos="0" dir="up" vMax="60"/>
<speedChange pos="0" dir="down" vMax="40"/>

Alternative B (suspected common use):
<speedChange pos="0" dir="up" vMax="60"/>
<speedChange pos="100" dir="down" vMax="40"/>

There is one aspect I did not raise in my previous post, which is the handling of sections that are equal in the two directions. Here there are three alternatives:

Alternative 1 (no @dir):
<speedChange pos="100" vMax="80"/>

Alternative 2 (with @dir as Alternative A):
<speedChange pos="100" dir="up" vMax="80"/>
<speedChange pos="100" dir="down" vMax="80"/>

Alternative 3 (with @dir as Alternative B):
<speedChange pos="100" dir="up" vMax="80"/>
<speedChange pos="2xx" dir="down" vMax="80"/>

Alternatives 1 and 2 are equally compatible with Alternative A, while I assume that a generator using Alternative B would always use Alternative 3. I will check which alternatives are used by the different railML certified software available to me, and I welcome you to do the same. As I have already stated, I find A+1 (or A+2) to be the preferred way, but it is more important not to break interfaces already in use. So if there is a consistent common way, we should keep it and document it.



Quote:
>> Suggested change:
>> * Document what part of the track the new values apply to
>> when using the @dir attribute
>
> I can do it if Christian Rahmig agrees and/or if there will be no objections here.

Absolutely no objections from my side! I am thankful for any
contribution. I suggest to do it on the discussion page of element
<speedChange> in the railML wiki
(https://wiki.railml.org/index.php?title=IS:speedChange). Once, we have
an agreement on the final solution, we may integrate it as "Best
Practice" on the main wiki page of <speedChange>.


I would be happy to contribute on the wiki. However, my request for access long ago was never answered.



Quote:
>> Suggested changes:
>> * DEPRECATE @dir for brigde, levelCrossing, platformEdge,
>> serviceSection (?) and tunnel
>
> I think is is a misunderstanding:
> The intention behind @dir was never to encode that the tunnel or bridge is not visible for the other direction.
> The intention may have been:
> <tunnel @pos=1234 @length=200 @dir=up> = a tunnel from km 1,234 to 1,434
> <tunnel @pos=1234 @length=200 @dir=down> = a tunnel from km 1,034 to 1,234
> This would fit in a certain way to the way <speedChanges> are to interpret from @dir.
>
> However, I have no objections against killing this redundancy and deprecate @dir from brigdes, tunnels etc.

For final answering this question I would like to receive more feedback
from the community. Do we want to introduce a rule that says:
"infrastructure elements with length have to be defined always in
direction of the track orientation (increasing @pos)"? If there is a
majority supporting this approach, we may think about an implementation
(in railML 2.5?).


I never meant to suggest that we should interpret a <brigde dir="up"> as solid ground in the other direction. I just meant that using @dir at all was illogical for these elements. I think Dirk's suggestion is the most probable for what the intended purpose may have been. Still, until confirmed we do not know if this was really the intended use, and how logical it is depends on how you interpret @dir for <speedChange>. As long as there is no documented way to interpret @dir for bridges and tunnels, we need to do something. We cannot have different software interpreting the location of a tunnel differently. From the existing documentation of @pos (distance from <trackBegin>) I would assume that Christians proposed rule was already established, making @dir redundant. (If you really, really need tunnels going backwards, @length allows negative values...)


Best regards,
Thomas
Previous Topic: [railML3.1] TrainDetectionElement and TrainDetectionElementSection
Next Topic: <track>@mainDir
Goto Forum:
  


Current Time: Sat Nov 17 16:19:54 CET 2018