Log In
Register Now!
Help
Please note how the longitude lines on the above map vary in direction -- in the area around the Black Sea they're vertical whereas in eastern China and Japan they're at a sharp angle. On the west coast of the US they're also at an angle but one that is opposite that of east Asia. These differences are significant in MSTS because what KUJU did is to start with a map like the above, grab an area of data bounded by the lines you see in this map (a quad of varying angles) and skew the data into a square -- now called a MSTS tile.
That changes distances on all tiles relative to actual distances on the map. Here is how it works using an example from the US West Coast:
The KUJU selection is in white and the original map data is in gray (note the actual distances from corner to corner):
How that selection compares to-be-projected MSTS tile:
What the distances are within the tile after projection:
That is all good and fine if, and only IF everything that goes into MSTS is also taken from a map that uses the Goode-Homosoline projection. Unfortunately, that is most often not the case. ALL of the USGS digital elevation data is projected in other ways... as is google... as is USAPhotoMaps... and AFAIK just about any source of map data one can fine.
Given that reality of source data the end result of mixing projection types is that all MSTS distances measured on the diagonal are all wrong. In this specific example I show above what in the world is ~3200m apart, measured SW to NE is now only ~2900m apart in MSTS. Comparing the NW to SE angle, what in the world is ~2550m apart is now ~2900m apart in MSTS. What is due north/south in a KUJU tile is also wrong -- in reality a north/south alignment should be SW to NE!
IOW in the example shown all distances running SW to NE are ~10% shorter in MSTS; All distances running NW to SE are ~14% longer -- per tile and all North/South alignments are pure fiction. AFAIK, this ruins the use of any available GIS data for roads, rivers, rail lines or imagery (e.g., Google Map images). How great the deviation from reality is is based on where in the world you target.
=====================
Issues:
The first thing is to choose a better projection method. Lindsay had a strong opinion on the matter in favor of a particular Ortho method and wrote it up in one of his posts(I'll have to find it to get the name). My gut feel is we consider that as our first (and perhaps only) candidate.
Second, AFAIK there is no open source equivalent to KUJU's RJE software which creates a quad tree structure for files holding game terrain and related data. To use any alternative to the Goode-Homosoline project will require writing a program from scratch to perform a similar function to the RJE program. Any enhancement of functionality will necessitate changing the file definitions and/or creating new side-by-side files for new features, paired with the old Kuju file format.
Third, AFAIK there is no open source software available to use to project DEM data from any source into any game file. Commerically DEMEX is still available; It's default mode is to project using the Goode-Homosoline method, tho if you fiddle w/ options you can project data using an alternative (and more reasonable ortho) method. DEMEX is as old as MSTS, it leaks memory like a sieve, it crashes, it uses obsolete raster formats to import DEM data -- lots of problems. The choice here is to work with Jeffery to revise DEMEX or write an equivalent program from scratch.
Fourth, if an Ortho projection is the go-forward solution what to do with all of the extant routes using the Goode-Homosoline projection? IMO the correct answer is nothing; IF there is a time when route level migration from MSTS to OR is called for I think the best answer is to assume the MSTS route is correct and not worry about the facts.
