I have commented on this topic 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
(You can skip this chapter if your want and will still be able to understand the examples below.)
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.
(To be continued in part 2)
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
(You can skip this chapter if your want and will still be able to understand the examples below.)
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.
(To be continued in part 2)
