[eric from trainsim]

I'd gladly accept a tool to draw out the curve for me based on defined XYZQ endpoints...

My normal method for track laying is to do the straight sections first, and then come back to do the curves. Thus, I've already got endpoints to feed into that type of equation because I'm already doing that to define the QD for the straights.

I'd thin you'd still need to define waypoints in the curve for setting grade and elevation. Following terrain isn't always desirable.

[Genma Saotome]

eolesen, on 15 January 2017 - 11:56 AM, said:

I'd thin you'd still need to define waypoints in the curve for setting grade and elevation. Following terrain isn't always desirable.

I agree. That's why I was thinking about a line between two points. If point A is 0.25m above ground level and you way a grade of 0.6% to point B the process should (1) provide enough information to accomplish that goal and (2) give you visual feedback via the drawn line of where the various cuts and fills will go on line AB.

The downside to the Line AB approach is that situation where you really do want the track to undulate up and down with the terrain and so I suppose there must be an alternative that says draw the line right with the line of terrain... which I think is pretty much an ordinary Boolean operation between intersecting faces.

And as a reminder, IMO route building is VERY much a 2d and 3d modeling exercise and the editing software must recognize and support that.

[WaltN]

This is a supplement to Dave Nelson's post:

Genma Saotome, on 15 January 2017 - 09:52 AM, said:

A couple of decades ago both Walt and I owned and used the same 2d drafting tool (I don't recall now which name it had at the time so I'll use the modern one which is VCADD).

The tool Dave is speaking of is Visual CADD. I became familiar with it in the late 1980s when it was known as Generic CADD. When I retired from IBM in 1991, I adopted Generic CADD for all of my 2D drawing needs. Generic CADD changed hands at least twice (once bought by AutoDesk) and was eventually acquired by TriTools Partners and re-branded as Visual CADD. It is now at Version 7. (I am still at Version 6.) Version 7 is getting pricey, but there is a 30-day trial version available if you explore their website.

Dave's recollections are pretty accurate. If you want to close two intersecting tangents with a desired radius arc, the simplest way is to specify a fillet radius (FR), then type FI (fillet), and you will be prompted to select the lines. Shazzam! I'm a creature of old habits, and I construct two parallel lines (LL) separated by the desired radius. Where those two lines intersect is the center of the arc. There I draw a circle (C2) with the specified radius. Then I break the circle (BR) and trim (TR) the arc and tangents. When the two tangents are close in azimuth, the results (even in double precision) can become inaccurate. For that, I have an alternate construction. The point is, "To each his own."

I apologize for the length of rest of this post. I felt it was important to mention the experiments I'll describe, and I kept typing until I felt I was done.

My habit is to use procedural (so-called "dynamic") track for curves and odd-ball lengths of straights. Turnouts, bumpers, etc. are static sections. I had a summer job on a Pennsylvania Highway Department surveying team in 1958 and got a good sampling of design/surveying phases. (We blazed a trail for estimating contractors to walk in a snake-invested woods near Wind Gap, we did pre-grading stake-outs, including ramps and borrow pits, of I80 in the Delaware Water Gap area, and a final post-construction survey of PA-248 near Palmerton.) Later (in the 1970s), I got involved with a programming language called APL as a part of my work for IBM. I ran into a guy who was doing an APL version of COGO (a subsystem of MIT's Integrated Civil Engineering System). I, as a co-author of APL GRAPHPAK, offered to add 2D graphics support and did. As a result of this experience and continuing research, I've modeled my route design process after real highway and railroad design processes. ("Route Surveying and Design" by Meyer and Gibson is a used book I acquired in 2010. It includes discussion of railroad practices, but the primary focus is on highway design. It is the principal reference for my report on spiral easement curves. It is still available from used book sellers. The libraries of universities with engineering schools are another good source.)

Back to VCADD: It has a documented API with which users can add their own functionality. (Goku might consider designing such an interface for TSRE5.) As an exploratory experiment, I added route design functionality to VCADD via the API. I started with waypoints (markers). I added a function (RT1 - GetWaypoints) (I right-away ran into collisions with standard two-character mnemonics, so I resorted to three. RT stands for "RouTe.") RT1 reads the waypoints file, and VCADD plots them with a '+', which is VCADD's standard representation for a point. (Typically, I work with two digits worth of waypoints at a time. For me, that's typically a few miles.)

I used another custom command (RT2 - StartAlignment), to identify the starting point for an alignment. (In surveying jargon, an "alignment" is a sequential group of path primatives -- straight line segments and curve segments.) The starting point can be one of the waypoints or an arbitrary starting point defined by its coordinates. Recognizing that some waypoints have some "noise" associated with them, I don't try to define an alignment that goes through all the waypoints. Rather, I try to get a "best-fit" straight line of reasonable length. Determining straight versus curve is entirely a judgment call. I then do the same thing for the next group of waypoints which, in my judgment, constitute a straight. Now that I've got two tangents of arbitrary length (consider them as unlimited length), I construct a circular curve that joins the two tangents. There are various situations here. Sometimes you'll want to specify the radius based, for example, on speed limit; in others, you'll want to take whatever radius the geometry gives you. It's entirely up to your, the designer's, judgment.

This process works quite well. I've used it for about 40 miles worth of DL&W track from Ithaca to Owego in New York State. I use VCADD to design yards too, with the few turnouts I've selected for use drawn precisely by VCADD. Of course, that's all in the (x,z) plane.

That brings me to the "curtain" mentioned by Dave. Dave's curtain is what real highway and railroad route designers call a "vertical profile" for an alignment. A vertical profile can be represented by a 2D plot of y versus s, where s is the distance along the alignment. Part of the job of a real route designer is to minimize the amount of cut and fill required over a region. Also, rarely does the volume of cut turn out equal to the volume of fill, in which case it is required to identify "borrow pits," from which fill can be provided and later returned from a cut. At least we don't have this problem!

Back to my experiments: After I constructed and grouped connected straight line segments and circular arc segments, I wrote a binary file representing the alignment. Then, I implemented RT4 - GetProfile, a VCADD auxiliary command that fetches the (x,z) path and interpolates (s,y) from a terrain y-file. The results were clearly wrong, and I need to give the code much more thought to uncover the source of the problem. It might be a problem with my interpolation code. I may have screwed up the coordinate conversions. It might be the "plywood effect." It might be all of the above.

One thing is clear, however: When I try to maintain a controlled vertical profile "by the seat of my pants" (meaning with just the MSTS route editor and me at the controls), I end up with a profile that "hunts" (wavers) around the desired profile. I need the help of a grade designer.

[Genma Saotome]

Great comments Walt.

I may be wrong but I rather doubt there is a necessity for everyone to purchase VCADD to get this functionality... what's been described is a tiny subset of the whole. Surely the concepts can be reverse engineered and applied in a modern route editor, if for no other reason than to produce a better set of markers.

I used to use VCADD to design model railroads (I was a long time member of the Layout Design SIG) and so the notion of simply expanding the scope from 3.5mm/ft to 12 inches/ft is no big deal.

I cannot emphasize enough for the need to be able to switch back and forth between 2d editing and 3d editing. It's not just laying out 100 miles of mainline, its projecting and painting terrain as well. I did an experiment on my Cal-P to see what it would take to create 100km of distant mountain terrain. The most straightforward way with DEMEX (a 2D GIS tool) was to create ordinary terrain first and then project the DM from that. So I did. All 63,000 tiles worth. Needless to say there is no way that could be accomplished one tile at a time. Applying the terrtex art to the 4 million patches was also done in 2D via Mosaic. One can select tens of thousands of patches at once and apply a texture to it.... tens of thousands of other patches, etc., etc. No way could 4 million patches be done one patch at a time.

When John gave up developing DEMEX he left a few clues in his last version which, IMO, clearly pointed the way he was going, which was using a 2d map to lay track in a route. Can't tell from the tea leaves whether he was thinking procedural track or not but the point is this was back around 2006. It was a great idea then... and still is today.

[WaltN]

Genma Saotome, on 16 January 2017 - 11:49 AM, said:

I may be wrong but I rather doubt there is a necessity for everyone to purchase VCADD to get this functionality... what's been described is a tiny subset of the whole. Surely the concepts can be reverse engineered and applied in a modern route editor, if for no other reason than to produce a better set of markers.

You're absolutely right! I wanted to mention that I started something like that (my first attempt at a GUI), but I thought I had gone off too long. I got stalled when I tried to make the two-character interface -- not because it's difficult, but because I'm too inexperienced with that sort of thing. The idea was to do just enough of a 2D route-drafting program to do route design in the (x,z) or (y,s) plane.

[BillC]

WaltN, on 16 January 2017 - 03:25 PM, said:

You're absolutely right! I wanted to mention that I started something like that (my first attempt at a GUI), but I thought I had gone off too long. I got stalled when I tried to make the two-character interface -- not because it's difficult, but because I'm too inexperienced with that sort of thing. The idea was to do just enough of a 2D route-drafting program to do route design in the (x,z) or (y,s) plane.

Walt, you may want to look at this LibreCAD . It is open source and use's QT as the GUI, which may fit in with Goku's code.

[WaltN]

BillC, on 16 January 2017 - 10:46 PM, said:

Walt, you may want to look at this LibreCAD . It is open source and use's QT as the GUI, which may fit in with Goku's code.

Thanks Bill.

My initial impression was good ... until I started checking out aspects of working with the source code. The prospects of working with another IDE was kind of a turn-off. I've got an investment in time and experience in VS. Checking out the prospects of building source with VS, I wouldn't want to get into this sort of thing. (It gets worse: It took me 15 minutes to figure out how to trap a "permalink," which is what it takes to capture a URL for a page in the LibreCAD forum.) Better to start from scratch. (I do have to confess that the "scratch" is not extreme scratch. I had OpenTK walk away from me after years of investment, and I'm still spending time figuring out what to do about that.)