Home » railML newsgroups » railML.infrastructure » Position of spotLocation and definition of length@value
Position of spotLocation and definition of length@value [message #3943] Fri, 20 March 2026 15:13 Go to next message
Torben Brand is currently offline  Torben Brand
Messages: 211
Registered: March 2016
Senior Member
I have received a railML3.2 file containing a road bridge with a spot location and a length.
See code bellow.
I assume for overCrossings the spot location is in the center of the bridge above the center line of the track? I do not see the wiki page [1] being quite clear on this.
If we use spotLocations for underCrossings (tunnels) we usually have defined the position on the beginning of the object.
Do we need an attribute to define the position of a spotLocation for items with a length?
We prefer to use <linearLocation> for items with a length to avoid this ambigiuity. Should this be a best practice in the wiki?

I assume the length@value is along the track (as reference is to the netElement and only the track has one. Not the road bridge itself.) So, for a bridge crossing a railway track, the regular "length" value in railML3 is the width of the bridge along the center line of the track.

I assume the length is evenly distributed when used in connection with a <spotLocation>?
I do not see the wiki page [2] being quite clear on this.

Most elements which have a <length> run along the track (line, platformEdge, track, undercrossing) The exception is the element overcrossing which normally runs across the track.
Is there a need to transfer information on the actual length of the bridge/overcrossing? In this case we could add a value to length@validForDirection="perpendicular" (although the angle might not be exactly 90 degress)?

<overCrossing id="3" constructionType="bridge">
          <name name="Agnes" description="Bridge over railway" language="en" />
          <spotLocation id="c5" netElementRef="ne36" intrinsicCoord="0.67668" applicationDirection="both">
            <linearCoordinate positioningSystemRef="lps_fln-g" measure="468126" />
          </spotLocation>
          <length value="15" type="physical" validForDirection="both" />
        </overCrossing>

[1] https://wiki3.railml.org/wiki/RTM:spotLocation
[2] https://wiki3.railml.org/wiki/IS:length

Report message to a moderator

Re: Position of spotLocation and definition of length@value [message #3950 is a reply to message #3943] Mon, 30 March 2026 10:35 Go to previous messageGo to next message
Dominik Looser is currently offline  Dominik Looser
Messages: 48
Registered: March 2020
Member
Dear Torben,

Thank you for raising this question.
I think a spotLocation with a length should always count from the beginning, not the center. This would be a consistent rule for all elements, no matter if they are usually short or long. For "long" elements like platforms, I think it is natural to place them at one beginning, while for level crossings I understand the argument that the center could be more important. Still, I am in favor for a univeral solution here, which could also be using <linearLocation>s instead.

Best regards,
Dominik Looser
trafIT solutions gmbh

Report message to a moderator

Re: Position of spotLocation and definition of length@value [message #3965 is a reply to message #3950] Fri, 17 April 2026 11:14 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 555
Registered: January 2016
Senior Member
Dear Torben and Dominik,

we raised this question in an earlier forum post [1], for which we have not received any feedback. However, we can discuss the topic now in context of railML 3.4 development.

In this older post, we proposed the following:

Cases in order of preference:
1) <linearLocation> + (@intrinsicCoordBegin and @intrinsicCoordEnd) or (<linearCoordinateBegin> and <linearCoordinateEnd>)*;
2) <spotLocation> + @intrinsicCoord or <linearCoordinate>* + length;
3) <spotLocation> + @intrinsicCoord or <linearCoordinate>*.

* mandatory according to the positioning approach [1]

Interpretation of the above three cases:
1) Data on both beginning and ending of -crossing is provided;
2) Coordinate provided represents beginning of -crossing, length is known;
3) Coordinate provided represents the centre of -crossing, length is unknown.

Please let us know your ideas on this approach.

[1] https://www.railml.org/forum/index.php?t=msg&th=958& goto=3277&#msg_3277

Thank you very much and best regards
Christian

Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: Position of spotLocation and definition of length@value [message #3985 is a reply to message #3965] Fri, 01 May 2026 13:47 Go to previous message
Silvan Gruber is currently offline  Silvan Gruber
Messages: 11
Registered: July 2024
Junior Member
Dear Christian,
We prefer to have one single possibility to locate linear Elements, which sohuld be:
<linearLocation> + (@intrinsicCoordBegin and @intrinsicCoordEnd) or (<linearCoordinateBegin> and <linearCoordinateEnd>)

If "spotLocation" + "Length" is allowed for linear Elements, then from our point of view the following restrictions would have to be taken into account:
  • Linear elements may only be located using "spotLocation" + "length" if the element does not extend across multiple NetElements, because the extent should be determined unambiguously.
  • When using "spotLocation" + "length", the located point must always be at the beginning of the linear element. Specifying `applicationDirection`shall be mandatory and must not be set to the value "both".
Further restrictions may become necessary.

Best regards

Silvan

[Updated on: Fri, 01 May 2026 13:55]

Report message to a moderator

Previous Topic: [railML3] Usage of <ownsPlatform> vs <ownsInfrastructureElement>
Next Topic: [railML3] Remodelling levelCrossingIS in railML 3.4
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Jun 17 05:44:53 CEST 2026