TransDEM Forum

I have risen this issue a few times in the past, occasionally with figures, but not with "hard evidence". Since it has come up again recently, I'll present a few pictures this time.

The article illustrates that TransDEM routes and the Trainz assets Lat/Long Reader and its sibling Trig Station don't fit together. It will only just touch the mathematical reasons behind the problem and then show practical examples. They should make the story clear without too much theory.


Introduction and Background

Mother Earth is round. Her shape is similar to a sphere. In contrast, the Trainz World is a two-dimensional flat plane. You can add mountains as a third dimension but the underlying Trainz world is still flat. Process and system memory permitting, you can extend your route with an endless number of baseboards in one direction and would never come back to the point where you started. In the age of discovery, the first seafarers made it around the world. In Trainz, they would never have succeeded. Fortunately, trains do not run across oceans.

To get from a point on the surface of the globe to a point on the flat Trainz plain, you have to kind of unwrap that surface. It's like peeling an orange and flattening the peel. As we all know, the peel will stretch and tear during that process. That means there will be some sort of distortion, loss or error in the final result.

Latitude and Longitude are coordinates to identify points on the surface of the globe. In contrast, on a plane surface you usually have an x and a y axis to find points. Cartographers have invented so-called map projections to get from lat/long to x and y, to peel the orange, and they try to keep distortion to a minimum. There are quite a few different map projections. None is without error and most of them are designed for specific purposes. A guy called Mercator defined a very famous projection which bears his name. It is still used for naval charts, and it helped the seafarers to do the full circle.

A more modern variant, the Universal Transverse Mercator (UTM) projection is the most widespread projection for topographic maps, and that's also the one TransDEM uses to flatten the orange peel.

The purpose of TransDEM is to bring cartography or maps from the real world into the Trainz world, from the round globe to the flat plane, from lat and long to x and y. And for that, UTM comes in handy.

But before TransDEM appeared about 10 years ago, Trainz already had lat and long. You could place a World Origin object anywhere in your route and assign arbitrary lat/long values to it. You could walk around on your Trainz plane in x and y direction and read individual lat/long values for any location on the Trainz surface, with the help of a little tool, Lat/Long Reader or Trig Station.

What was the purpose of the built-in lat/long feature? The makers of Trainz never claimed, it was suitable for geo data. What is apparently does do is to control the solar orbit (in simulation worlds, the sun rotates around the earth) and hereby the lighting of our scene, quite an important task.

To make this work, the Trainz developers had to implement one of those map projections, to convert between lat/long and x/y. They did not tell us which one they used. It is not UTM, though. And that's where the trouble starts.

Now we have two map projections, Trainz internal via Lat/Long Reader and UTM via TransDEM. And the two yield different results.

Some say, yes, true, but only of academic interest, since the discrepancies will be small, an error of perhaps one percent or so, and can be safely disregarded. The following examples will show that that assumption is not justified.


Example route

The route to illustrate the lat/long issue is in Santa Fe territory in New Mexico, USA. Original Raton mainline down the Rio Grande Valley from Albuquerque to Belen and then eastward on the Belen Cutoff through Abo Canyon and Mounatainair. It's a medium size route, about 60 km north from Belen and 60 km east (38 mi). For reasons having to do with the math behind map projections I wanted an area with a route primarily heading north and east, the primary axes of many projections.

DEM is 1/3 arc sec NED and maps are OSM. Orthoimages on UTM tiles by Bing.



The triangles mark the sample locations.


World Origin

I let TransDEM set the World Origin of my route to the baseboard of Belen Railway Station (Rail Runner stop). Lat/long are N 34° 39,862', W 106° 45,846' and N/W corner UTM coordinates are [338000, 3837600]. These values are fix. If you build a similar route with the WO on that particular baseboard you will get the very same coordinates, without further ado. That's because of the static mapping between UTM and Trainz World Coordinates as baked-in by TransDEM.


Test 1 Belen

The first location to examine will be Belen station building (Rail Runner stop), north of the big Sante Fe yard. This point is 260 m (850 ft) south-west of our World Origin, very close. I set a placemark in Google Earth and examine the lat/long coordinates. I change the display format to decimal minutes because that's the same format as in Trainz. We get 34° 39.789'N, 106° 45.986'W.



Then I switch to the Trainz route and place a Lat/Long Reader object which I move to that same position, guided by its lat/long reading. And I end up where I should, right on the roof of the station building (although it may not be that easy to see, as the image is quite blurred).



There is nothing wrong here, no noticeable discrepancies.


Test 2 Albuquerque

Let's move on, 48 km north (30 mi), to Albuquerque and another, bigger railway station. I pick the rooftop in Google Earth and read: 35° 5.003'N, 106° 38.867'W.



Then I place a new Lat/Long Reader in my Trainz route and move it around until the coordinate reading matches that of the Google Earth placemark. It takes quite a while and I am getting further and further away from the railway.



Finally, I find the spot, but now nearly 850 m away from the railway station, to the west. That's half a mile or half-way across downtown! A very significant discrepancy. Obviously, the Lat/Long Reader is of no use here.


Test 3 Mountainair

Let's verify this at a different point. This time we are going east, to Mountainair, 52 km or 32 mi from Belen. In Google Earth I get 34° 31.155'N, 106° 14.272'W for the historical depot building.



Moving another Lat/Long Reader to the equivalent position, I find myself 680 m north of the station or 2200 ft. Again, a rather useless measurement.




Test 4 Abo Canyon

You may argue that you don't want to use raster maps or orthoimages in Trainz anyway and only rely on individual lat/long readings and interpolate between them. Then it wouldn't be that bad.

But you still have the DEM. And wasn't that the whole idea, to get your terrain shaped automatically? The Albuquerque and Mountainair examples were located in a flat area (DEM-wise). So, for the last test we travel to Abo Canyon, which is also closer to Belen. The point I pick is 44 km / 27 mi from Belen. It's a small railway bridge over a wash. Google Earth tells me 34° 26.331'N, 106° 22.606'W.



In the Trainz route, my Lat/long Reader leads me 554 m away from that bridge (1/3 mi). The wash (or arroyo) is nicely modelled in my 1/3 arc sec DEM, but the Lat/Long Reader brutally relocates me into the hills.



So now I either have to abandon the DEM as well or the Lat/Long Reader. More correctly, since the Lat/Long Reader is only the messenger: I have to abandon the method of taking lat/long readings from Trainz built-in geographic coordinates. They are misleading. To an extent which makes them unusable.


Who's to blame?

So, whose fault is it then? Fortunately, no one's! There is no one to blame.

• Not the creators of Trainz, because their lat/long projection was never meant to be used for cartography.
  
• Not the authors of the Lat/Long Reader and Trig Station tools, because they simply extracted the data from Trainz and had no means of testing the result against proper geo data.
  
• Not the users of the Lat/Long Reader and Trig Station because you need expert knowledge to understand that lat/long may not always be lat/long.
  
• And not TransDEM, because TransDEM just picked a well established, standard solution to directly map Cartesian and metric Trainz World Coordinates to Cartesian and metric UTM coordinates, using the Trainz World Origin solely as a reference point for the offset between TWC and UTM.

Findings about the Trainz internal map projection

The samples we took are too few to draw conclusions about the Trainz internal map projection. What we know, the closer we get to the World Origin object the smaller the error. And the error is systematic. It appears to be somewhat dependent on direction angle. The magnitude of the error is between 1.3 and 1.7% for the samples. Sounds small but isn't as the screenshots with the rulers clearly illustrate.

What has confused me are the direction angles of the displacements in each sample. It's pure speculation, but they could indicate a false easting for the Trainz internal map projection. That projection could be a zonal one, like UTM. And the earth radius in its parameters is probably too small.


How accurate is UTM?

If you remember the flattened orange peel you will be aware that no map projection can be error-free. But all of them try to minimize the error for a specific purpose. UTM, the Universal Transverse Mercator projection is conformal but not equal area or equal distance. With these terms cartographers classify projections. Conformal means that any angle measured in the real world will become the same angle on the map. Turning right 90 degrees on a road intersection on the map will mean exactly 90 degrees in the real world, for any location on the map. Equal distance would mean that 1 km on the map would be 1 km in the real world. UTM is not equal distance, it cannot be, but it comes close. Near the origin of any UTM zone (every 6 degrees longitude), the kilometre is little bit shorter on the map than the original and near the border of a zone it's a bit longer. It's not much, just a metre or two, when 200 km away from the zone origin, for moderate latitudes. An error of 2 metres on 200 km. Or 1 in 100,000.

For the Trainz map projection we found – comparing to UTM – an error of 500 m on 50 km, or 1 in 100. (It was actually worse, more like 1.5 in 100, but let's keep it simple).

1 in 100,000 vs. 1 in 100. That's a factor of 1000. So, UTM appears to be 1000 times better than Trainz' internal lat/long coordinates.

Since the UTM error is so small, we can easily extend our 6 degree zone with another one, something we frequently do with a TransDEM route. And that has a counterpart in the real world, too. In Italy, for instance, the “heel” of the “boot” theoretically lies in a different zone. For simplification, the Italians just extended their main zone and this way only need one zone for the entire country.


Conclusion and Alternatives

Well, stating the obvious, do not use Lat/Long Reader or Trig Station, not when you are building with geo data and TransDEM. (Would also apply to projects involving MicroDEM/HOG, MapMaker and the various categories of "basemaps".)

• Use built-in TransDEM functionality. Don't stop with geo-data after having acquired the DEM. Add maps and/or ortho-images, or vectors. Apply them to ground textures, UTM tiles, or splines. Much quicker to handle than the cumbersome process of identifying individual coordinates of each point-of-interest and transfer them to the Trainz route
  
• If you really think you need point coordinates, use UTM and TWC, not lat/long. Follow this tutorial to set it up. Similar effort but accurate results.
  
• Relocate the World Origin to always stay close to it. Well, that is what you may think. However, this idea is not going to work. The reason is simple: To relocate the World Origin you have to know the “true” coordinates of that new reference point, since Lat/Long-Reader will mislead you. Unfortunately, you would have to resort to one of the other methods mentioned. Hence, even more work this way.