Project: TS2013/4 Route Mapping program

[rivimey]

New release 0.8.2

I have uploaded a new release which fixed the last DLL dependency error (I hope): I tested it on a blank Vista install and all seemed well.

Go to https://github.com/rivimey/rwmapmaker/r ... /tag/0.8.2

Download the setup file or be brave and install from source!

[rivimey]

I will knock up some pseudo code tomorrow. I looked at the function you linked to, looks good to me is all I can say right now.

I totally agree that these ideas with the signal links are the most ambitious on the whole list. I just presented all of my wish list to encourage people to join in with their ideas or to give me feedback on my wish list or whatever.

Thanks very much for the offer... As you see I have now got a working release posted so please do have a go and see what you think!

Ruth

[AndiS]

I fell asleep yesterday when doing the pseudo code.

I must admit that my knowledge of C++ is minimal. For historic reasons I moved from C to Java back then. Most of the stuff I do is Perl with no user interface.

I had a look at your source code yesterday, and I guess I figured out what it does. But the more important bit is that I retest my theories and put them down very concisely. If not tonight, than tomorrow or the day after ...

[rivimey]

Thanks for your thoughts on the code, Andi...

Has anyone else had the courage to try it?

[ Remember, you can (currently) only use it properly on routes that don't include the zipped filesets, which is any route you've made and many downloaded from 3rd parties. ]

[Nobkins]

Hi Ruth,

I have had a quick go. Hope to give you more feedback in a few days once I come off my shifts.

Jim

[AndiS]

Ok, here is what I know:

Code: Select all

polylen = the length of the line segment as for the arc
polycount = number of segments
startangle = tan(StartTangent[1] / StartTangent[0]) // as for arc and straight
if TraversalSign == 1 {   // from straight to arc
   radius = 1 / Sharpness / (Length + L0)
   for (i = 0, s = 0; s <= Length; s += polylen, i++) {
      points[i].x = s * s / 6 / radius
      points[i].y = (s==0) ? 0 :(s - 9 /10 * points[i].x * points[i].x / s) * CurveSign
      }
   rotate all the points around 0/0 by startangle
   translate all the points by X-Coordinate/Z-Coordinate in StartPos
   }
else {   // from arc to straight
   radius = 1 / Sharpness / L0
   // calculate points for s going from L0 to L0-Length, i.e., towards the straight end
   for (i = 0, s = L0; s >= L0 - Length; s -= polylen, i++) {
      points[i].x = s * s / 6 / radius
      points[i].y = (s==0) ? 0 :(s - 9 /10 * points[i].x * points[i].x / s) * CurveSign
      }
   rotate by L0tangent?
   flip horizontally around end point
   rotate by startangle (around same point)
   translate to StartPos
   }

What I established is the bit about calculating the x/y coordinates for the raw curve, i.e., horizontal. The values in L0Offset are just that, i.e., you set s to L0 in the above formulas and you get these values. Mismatches I got earlier were caused by discarding relevant digits. Sharpness is a small value, it must be taken at its full precision. E.g. 2.15328e-005 = 0.0000215328 = 1 / 116.1 / 400 (Sharpness = 1 / L0 / radius at the tighter end of the easement).

What I did not master is this rotating business. I got the formulas for rotation in 2D, but I did not manage to integrate them into my spreadsheet to verify my theories. However, the above sounds pretty logical to me.

[rivimey]

Thanks Andi. Ill give it a go at the weekend and see what I make of it when it comes to hard code.

I always like to understand constants in maths code... do you know where the 9/10 and the s/6 come in?

[I never understood why what we would normally call 'Y' coord is called 'Z' in kuju-speak!]

Regards
Ruth

[AndiS]

There is always another can of worms.

The simple bit is this: There is a load of different labelling schemes for the three axes and traditionally, computer graphics people have migrated from 2D elevation view where Y is up to 3D where Z is that new dimension. Amazingly enough, positive Z is nearer to the viewer, or south in RW. Z sorting is when the graphics engine decides what you see (among various objects in a view of sight).

The formulas arrive from two different sources and Kuju know why.
Basically, the ideal clothoid
In engineering practice, people like to draw precise stuff on paper. So they needed formulas that lent themselves to do that. The above method did not.

One popular approximation is the cubic parabola, nicely explained here together with a little background on superelevation. The original formula is
y = x³ / 6 / L / R
with R the radius at the end, L the total length, and x the horizontal position.
However, Kuju positively measured x along the track, not along the horizontal axis.
For the end of the curve, x = L so it becomes the formula I showed. Don't ask me if I messed up there, but when you draw an easement in many segments (by clicking the mouse every 10 m or so), you get exactly the figures I showed.
I called the Y in the formula X to suit the other formula. I also called the length measured along the track s in keeping with the other formula (it does not have a name in the formula of the cubic parabola).

Note that now you are at a loss as to the other dimension - y. Input: s = running length, output: x = position along the horizontal axis. The original formula used x as input and y as output, implying s because it is irrelevant when you draw on paper.

I agonized over the missing dimension for a few years and then came across some American tests containing the other formula.
Then I came across the other formula. It was in some American text book from 1901 downloaded from archive.org. I just found it in the whole mess: Page 82, formula 56. Note that this is the chapter on street railways ... Anyway, I am truly glad to have found it again. I was sure I never made up such a thing, but in all the stuff that piles up on my harddisk it, so to say, it is not easy to spot the justification for each of my believes.

Please, don't get lost in this book. By the time you sussed out all the units of all the variables, you have plotted all the easements in RW in your map, and people would rather see that. And while it is great fun to read how people went about the task a century ago, it does not help you in a computer game at all.

[rivimey]

Andi,
That is a truly wonderful find. I've bookmarked it but will forbear the delving it deserves till another day!

Best wishes,
Ruth

[rivimey]

Started to do a bit of preparatory work on the easement issue.

Good news is the source (at tag 0.8.3) on Github now builds properly, though there is an issue (afaik unresolvable) that the setup project uses absolute paths to get the Qt DLLs etc so those compiling from source will have to fix that up. An alternate installer would fix this. The 0.8.2 MSI installer is still 'latest': all the changes in 0.8.3 are to the build system and source comments.

I've put up a website (on Github) for the project too: http://rivimey.github.io/rwmapmaker