TransDEM export into TANE issue

[Parsifal300]

I've run into an interesting issue with the exporting of Rail vectors into TANE. The vectors import fine but the junctions are incomplete and possibly causing more intensive issues than are first apparent.

I'm exporting a switching yard that covers about (guess) 50 acres and has over 75 junctions. After conducting a CM folder import of the TransDEM export files TANE surveyor does not show any switches or red/green arrows when the route is viewed at ground level. When the route is viewed from a Bird's Eye level about 20% of the junctions show red/green arrows.

I went through the process of manually fixing all of the junctions. The process was splitting junction apart and manually reconnecting the 3 splines. The junction and switch would appear but would be VERY sensitive to track changes around it. For example, fixing a second junction within 50 feet of the first repaired junction would usually cause the first repaired junction to break (both left and right arrows go red). Then if I simply clicked on a nearby spline point the first junction would return to normal. Note there was minimal movement to the nearby spline, just a mouse click to fix the adjacent junction.

I finally got all the junctions fixed, saved the route and had a well-deserved break. Upon going back into the route 80% of the junctions were broken again. The only junctions that were still working were the ones where I actually replaced some of the track segments going into the junction. Not sure if I had replaced 1, 2, or all 3 of the splines going into the junction, I was just to frustrated (yet) to go back and start experimenting.

The only non-default settings for vector export were naming the rail export layer to TransDEM-Rails and changing the junction default switch to KUID102446

Any help would be appreciated!
Thanks in advance,
~P

TANE build: 81318
TransDEM build: 2.6.0.1

P.S. I have a trouble ticket submitted into N3V but I don't know if this is a TANE or TransDEM issue. Just covering all the bases.

[geophil]

It could be a conversion issue and related to the different representation of vector data in the TransDEM and Trainz worlds.

In TransDEM we have a bunch of polylines which are not interconnected, in particular, there are no junctions. In Trainz we have a connected graph consisting of spline segments and spline control points. The latter can represent junctions. When converting, TransDEM applies an algorithm to identify potential junctions and joins a polyline endpoint to an intermediate point of a second polyline. Since TransDEM 2.6 there is also a manual snap function in the TransDEM polyline editor to assist that algorithm.

I suggest to have a closer look at the polyline endpoints for those junctions that show weird behavior in Trainz Surveyor. Do they match?

And, as always, there could be a problem with the TransDEM interpretation of the Trainz file structure.

[Parsifal300]

I discovered the snap function while creating the vectors. Once discovered I went back and verified the other vectors "snapped" into position before export.

The report back from N3V is TANE does not support direct imports from TransDEM. One is supposed to import into TS12 then import to TANE from TS12. Unfortunate for people that do not own TS12. I can only assume from the N3V statement this is most likely not a TransDEM issue.

Thanks for your help though, much appreciated.

~P

[geophil]

The report back from N3V is TANE does not support direct imports from TransDEM. One is supposed to import into TS12 then import to TANE from TS12. Unfortunate for people that do not own TS12. I can only assume from the N3V statement this is most likely not a TransDEM issue.

Bear with them. They don't have the resources to investigate and therefore cannot officially support data import through 3rd party software.

Technically and according to my analysis, spline data representation in T:ANE is only marginally different from TS12. T:ANE has to accommodate cant/superelevation and one or two other new attributes which I don't recall at the moment. But I haven't noticed any differences for junctions and junction levers. Of course, I may be mistaken here. (Junction levers are stored in the .obs file, not the .trk file.)