Точность расположения объектов в редакторе маршрута

[Zabor]

Рано я так обрадовался, получается, что мы меняем шило на мыло вот изменения в записи стрелки до правки кода формата вывода в W файл и после:

Elevation ( 0.000916297 )
JNodePosn ( -4973 15341 -734.123 22.4526 -586.943 )
FileName ( A1tPnt7_5dLft.s )
Position ( -734.123 22.4526 -586.943 )
QDirection ( 0.000450976 0.176259 8.07508e-005 0.984344 )

Elevation ( 0.000916 )
JNodePosn ( -4973 15341 -734.122986 22.452600 -586.942993 )
FileName ( A1tPnt7_5dLft.s )
Position ( -734.122986 22.452600 -586.942993 )
QDirection ( 0.000451 0.176259 0.000081 0.984344 )

Elevation - точность возросла
JNodePosn - точность возросла
Position - точность возросла
QDirection - тут все очень спорно, по некоторым значениям точность возросла, по некоторым снизилась в зависимости от разрядности исходника, а с некоторыми происходят странные метаморфозы, например третье значение 8.07508e-005 -> 0.000081 совсем неясно чем это грозит, понятно только что "e-005" какой-то бред, но столь значительное изменение целых с 8 на 0 пугает.

Что еще настораживает - а не пишем ли мы теперь обрезанные до 6 знаков после точки значения в БД? Ведь столь серьезное увеличение точности Position должно было дать практически идеальные стыки ниток в БД, однако, на деле это не совсем так, хотя и в допуске.

Также не очень понятно, почему код формата %e не мешал записывать в параметр QDirection значения вида 0.000450976 при этом обрезая значения в Position строго на шести разрядах независимо от числа знаков после точки, зато %f порезал или дотянул все значения всех параметров до 6 знаков после запятой.

Вероятно то, что писать в Position определяется где-то еще отдельно.

Еще странность варианты типа %.3f, %.8f, %.9f никакого впечатления на MSTS не производят.