[JeroenP]

Dear all,

Within a track database junctions are defined by their location in a UiD, e.g.

                TrackNode ( 1816
                        TrJunctionNode ( 0 21546 0 )
                        UiD ( -5584 14977 3019 0 -5583 14977 -1023.82 36.95 -77.917 0 1.71644 0 )

The tile is defined twice within the UiD. The first two numbers (-5584 and 14977) and the 5th and 6th numbers (-5583 14977). My question is: why is it defined twice? And more importantly, which set should be used for what, especially in the case that they are not consistent (as in the above case)?

Currently, as far as I can see, ORTS code just uses them interchangeably. But this can lead to a fail (see for instance Broken Path in Berlin, which contains a link to the real route : SFS Hanover-Berlin v3).

Anyone know exactly what the difference is between the two sets? Or can be safely simply ignore the first set and only use the second set?

Thanks, Jeroen

[roeter]

The first three figures define the World entry of the related shape : world-file tilex, tilez and UiD of shape within the world file.
The second series of figures define the actual junction position - depending on the junction shape, this may be a different position - some switch shapes have the junction right at the end of the shape, but others have the junction somewhere along the actual shape.
As the actual junction position can be different from the shape position, it can be in a different tile.
So, which numbers should be used depend on what you want to do. For display, for instance, the shape position must be used. But if you want to display the junction in the trackviewer, you probably should use the junction position.
I say 'probably' because there is a snag which means this all requires more detailed investigation. Each track shape has its consistent sections defined in the tsection.dat file. But the origin of these sections is the shape position. So, if you calculate the actual track section positions, which is what the traveller is doing, you should still use the shape position and not the junction position.

To visualise this a bit look in the route-editor : the shape positions are the blue 'telepoles', the junction position is the red 'telepole'. As mentioned, most switches have the junction at the shape end - which results in two blue and one red pole. Some have the junction somewhere along the track (scalerails is an example of this), these have three blue poles and one red pole.

Regards,
Rob Roeterdink

Some further thoughts on this (and a correction) :
in the TDB, the nodes run from junction to junction. The shapes are allready 'cut in pieces', the pieces being the consisting track sections, and the position of these pieces are the 'absolute' positions.
So, the traveller which uses the tdb will use these track section positions, the shape position should only be used by the viewer.

[JeroenP]

Rob, thanks.
OK, I get the idea here.

The origin of the question relates to the .pat file. The junctions in the .pat file are given in coordinates only. As far as I have seen these coordinates correspond to the real junction location. This is (I think) the same junction location available in the world-file for the corresponding shape and called JNodePosn. Apparently, in some cases the world-tile of the shape is different from the actual junction position (in this case the difference is only 38cm or so).
To be able to find the correct junction index corresponding to the junction as given in the .pat file, we therefore have to use real location only, and not the tile. In AIPath.cs, method FindJunctionOrEndIndex, therefore, we should not cull based on WorldTile but based on Tile only.

Since an actual issue was reported (see the link in my original post), I now think that was not a route issue but a real bug in ORTS.
Please let me know if you agree.

Jeroen.

[roeter]

Hello Jeroen,

yes, I agree that it is a problem - but only partly due to ORTS. The other part is due to location errors in MSTS.
When working on the signalling, I found one or two signals in different routes which were clearly located just in front of a switch (both were switch-stands), but the given location of the signal was such that it was positioned beyond the switch - as in the case you mentioned, the difference was just a few cm. I had to 'twist' the traveller a bit in order to make sure these signals were located in the correct track section.
So, in all it is a tricky business. But it is worth looking into.

Thanks,
Rob Roeterdink

[perpetualKid]

attaching related question here:

While working on some code related to parse TDB, wondering which part of the TrJunctionNode UiD should to be unique within a TDB file?

I came across a TDB which has those TrJunctionNodes

TrackNode ( 1116
TrJunctionNode ( 0 78 0 )
UiD ( -5643 15315 53 3 -5643 15315 498.14606 156.556 -561.49512 0 -2.2337501 0 )
...
TrackNode ( 1119
TrJunctionNode ( 0 78 0 )
UiD ( -5643 15315 53 8 -5643 15315 520.60498 156.556 -543.95502 0 0.90784401 0 )
...
)
TrackNode ( 1120
TrJunctionNode ( 0 78 0 )
UiD ( -5643 15315 53 11 -5643 15315 530.60596 156.556 -541.466 0 1.0823802 0 )
....


the marked sections of the UiD are the WorldTileX, WorldTileZ and the Index to the TrackObj in Worldfile. There is some code in the tdb parsing searches for the TrJunctionNode just by those 3 parameters and returns the first found, so it will never return any of the later ones. Is that correct, or is maybe the tdb file as shown above just wrong?


Also, does someone know wthat he 4th parameter (3/8/11 in above sample) stands for? OR just ignores this, and haven't found documentation.

btw thats what it looks like if you got a sign error in some math deep down in the code... :curiousPC:

[roeter]

The 4th number is the index in the path list (SectionIdx) in the trackshape definition.
Given the large number of the 4th index for the third entry, could this by any chance be a turntable or transfer table?
A picture of the layout of this trackpiece (preferebly from the trackviewer) would help to understand what is going on here.

Regards,
Rob Roeterdink

[dajones]

Track shape 78 is a A1tDblSlip10d.s, so there are probably 4 TrJunctionNodes with the same first three fields.

Doug

[perpetualKid]

dajones, on 16 October 2019 - 02:12 PM, said:

Track shape 78 is a A1tDblSlip10d.s, so there are probably 4 TrJunctionNodes with the same first three fields.

indeed there are 4, so seems this is expected and correct. I tracked down the other code and this only seems to link back to the track shape index, which is identical for all (78 here), so doesn't matter it only ever reads the first result

roeter, on 16 October 2019 - 01:57 PM, said:

The 4th number is the index in the path list (SectionIdx) in the trackshape definition.
Given the large number of the 4th index for the third entry, could this by any chance be a turntable or transfer table?

In related TSection, this shape only has 9 sections, so something is odd here (or I missunderstood):

TrackShape ( 78
FileName ( A1tDblSlip10d.s )
NumPaths ( 9 )
MainRoute ( 1 )
ClearanceDist ( 26 )
SectionIdx ( 1 0 0 0 0 335 )
SectionIdx ( 1 0 0 0 0 187 )
SectionIdx ( 1 2.4565 0 1.9371 -10 187 )
SectionIdx ( 1 2.53 0 1.52 -10 337 )
SectionIdx ( 2 2.4565 0 1.9371 -10 334 333 )
SectionIdx ( 1 -2.495 0 30 170 182 )
SectionIdx ( 1 -2.495 0 30 170 176 )
SectionIdx ( 1 0 0 40 180 187 )
SectionIdx ( 1 0 0 40 180 185 )
XoverPts ( 1
XoverPt ( 0 0 15.86433 )
)
)

However as said that number from TrJunctionNode is ignored, was just for curiosity.