Den 06.01.2020 16:23, skrev Christian Rahmig:
> In railML 3.1, the attribute @applicationDirection is
> documented like this: "direction in which the element is
> applied, related to the orientation of the <netElement>"
>
> What do you think: Is that precise enough?

I'm sorry, but no I do not think it is self-explanatory what "is
applied" means. Not any more than the previous "is valid". If you put
applicationDirection on a <track>, does it mean that the rails have been
applied (as in laid down) in that direction? What about "direction *of
traffic* for which the element applies/is applicable"?

Den 13.01.2020 15:09, skrev Christian Rahmig:
> Elements without extent (without @length attribute)
> examples: balise, border, derailer, signal, stopPost...
> usage: @dir describes the direction of travel, for which the
> element applies. Possible values are "up", "down" and
> "both". A missing @dir attribute means that the application
> direction of this element is unknown.
> proposal: DEPRECATE @dir for trackCircuitBorder

I agree

> Elements with extent (with @length attribute)
> examples: bridge, levelCrossing, platformEdge,
> serviceSection...
> usage: @dir describes the direction of travel, for which the
> element applies. Possible values are "up", "down" and
> "both". A missing @dir attribute means that the application
> direction of this element is unknown. By standard, the
> elements' orientation (not their application direction!
> shall be always in direction of track orientation (from
> trackBegin towards trackEnd).
> proposal: DEPRECATE @dir for brigde, levelCrossing,
> platformEdge, serviceSection and tunnel

Rather than writing about orientation, I would just write that the
extent of the element is from @pos to @pos + @length along the track.

> Elements that describe a change
> examples: axleWeightChange, clearanceGaugeChange,
> electrificationChange, gaugeChange, speedChange...
> usage: @dir describes the direction of travel, for which the
> change applies. Possible values are "up", "down" and "both".
> A missing @dir attribute means that the application
> direction of this change element is unknown. By standard,
> the change elements' orientation (not their application
> direction! shall be always in direction of track
> orientation (from trackBegin towards trackEnd).
> proposal: DEPRECATE @dir for elements where properties
> cannot differ by direction of travel, e.g. axleWeightChange,
> clearanceGaugeChange, electrificationChange, gaugeChange,
> ownerChange, powerTransmissionChange, radiusChange

What is the orientation of a change element? Are you referring to the
sign of the value for gradientChange and radiusChange? I think these are
the only two where orientation matters. For gradients, positive values
should always mean an uphill slope in the direction of the track. For
radii, positive values should always mean a turn to the right in the
direction of the track.