Error by evaluating and displaying TrackItems from the *.tdb

[Rippstein]

In the *.tdb, the locations of Trackitem (Signals, Speedpost, Milepost, Levelcrossing, etc.) are defined as follows, example entry in the TDB:
SignalItem (
TrItemId ( 3 )
TrItemSData ( 18.1304 00000002 )
TrItemRData ( 137.325 49.9499 -226.043 -5578 14978 )
TrSignalType ( 00000000 1 4.23109 Sig25VHp01_fH_jm )

there exist two Parameter to locate a TrackItem, which define the same point
TrItemSData ( ) is the distance in meters from the starting point of a track part
TrItemRData ( ) is a three-dimensional coordinate in space, for the same object

OR and MSTS process these coordinates differently to determine locations and function of TrackItems:

The MSTS consistently uses the same parameters for location of TrackItems:
MSTS-Simulator TrItemSData( )
MSTS-RE TrItemSData( )

OpenRails uses, in CONTRAST to MSTS, the space-parameter in its tools.
OR-Simulator TrItemRData( )
TrackViewer TrItemRData( )
BUT the TSRE5, the only route-editor for OR, uses the same parameter as MSTS
TSRE5 TrItemSData( )

*********************************************************
In order to ensure the compatibility of the OpenRail with MSTS, TrItemSData( ) should also be used in OpenRails and Trackviewer for the location of TrackItem
*********************************************************
The MSTS-RE has left many routes where the two coordinates do not indicate exactly the same position of a Signal. This is even so in the six MSTS original routes!!

Calculated with TrItemSData (MSTS simulator), signal A precedes signal B. Calculated according to TrItemRData (OR simulator), signal B precedes signal A. In the OR simulator, the signal sequence then appears as reversed, signal B is in front of A, which leads to disturbances of the signals.

This problem is probably also the cause of similar problems with other trackitems.

Surprising finding:
If I set the first 3 coordinates of TrItemRData ( 137.325 49.9499 -226.043 -5578 14978 )
to zero in *.tdb and *.tit
as this: TrItemRData ( 0 0 0 -5578 14978 )
then the problem in OR disappears and the signal A precedes signal B
and OR is handling the Signals correctly!
So it seems, that OR can handle also TrItemSData( ) for TrackItems, if the space-coordinates are not present.

see here:
http://www.elvastower.com/forums/index.php?/topic/35990-signals-too-close/
in Post:1,5,8,11