Creating a Map from Digital Terrain Data and Google Maps

[OilCan]

I have attached a step by step process for creating a RT3 map from digitial terrain data and Google maps.

In writing such instructions it is easy to leave out information or to be unclear. Please let me know if the instructions can be improved.
As always, there is more than one way to do something. These instructions do not cover all means and methods to accomplish the same goal.

When wedding a Google map image to a heightmap there will never be 100% agreement. The map maker will have to make touch-ups to the map colors.

[RulerofRails]

Wow, 18 pages! I am really grateful for this. I am trying to make a map, but I started thinking about storyline etc. and I go looking at some other maps to see how things were done. This causes me to find new maps that sound really interesting, I end up playing them so my progress is slow. I can only hope it turns out good enough to share.

[delacroixp]

Pretty exciting stuff.

I loved the Russian map in RT3 ... look fwd to something in TM.

There was much talk of a Trans-Siberian railway from Korea and Eastern Asia to Europe (esp for double-stacked containers)
... making the trip 3-times faster than by sea (15 vs 45 days).
Railways certainly can't compete with shipping in sheer volume but it could make for a very nice niche market.

Unfortunately TM can't simulate double-stacked container transport.
Double-stacking containers is probably the main route to financial success and railroad freight resurgence ... in Europe and the rest of the world (outside of the USA) .
40t/axle railways also show great promise in attracting heavy-haul cargoes.

I guess TM has simulated the decline of railways very well
(from the heydays of the 18th century to the ease of truck and road transport).
Perhaps we could still see a rise in the financial fortunes and the increase in market share of railways in global transport.

It's all good

Pascal

[Gumboots]

You can skin cargoes as double-stacked containers easily enough.

[delacroixp]

Looks mighty fine indeed and ... oops!
I meant to post in Trans-Siberian Railroad where thietavu is considering a new monster map in Siberia (along partly similar lines to his China map).

The graphic for double stacking container looks good but can you double-load a wagon to simulate a change from single to double-stacking?
I've only started TM a month ago but in Birth of a Nation (CA01) I'm using over 100 trains in the first five years.
It got me thinking that one heavy-haul train is better than 5 normal trains (which clutter up the works).

I've never run 600 trains on a massive China or USA mapped network (which should be interesting) ... but I still prefer a few monster trains to get the job done.
Naturally you don't want to sacrifice speed ... ultimately, the sheer volume of transported goods over a time period (eg 1 year) is what really matters most.

It's all good

Pascal


PS Sorry for butting in your thread.

[Gumboots]

No, you can't double load things. The game is unfortunately locked to 8 loads maximum. All you can do is change the visuals. For example, I made bauxite cars that have 24 visible cars in the late era, but from the game's perspective there are still only 8 loads.

Double and triple bauxite cars

[RulerofRails]

delacroixp, I'm not sure how much you have read on the various threads about V1.06 and TM. Both V1.06 and TM use all the available cargo slots (IIRC, that's 51). RT3 doesn't easily allow adding new cargoes for a specific map, but it is possible.

One could envisage setting up Warehouses to pack various cargoes into double-stack containers for long distance haulage. There is a slight snag when the process goes the other way: the unpacking. Any industry that has multiple recipes that all require the same input to give varied outputs is in some ways "broken" because the game will choose the conversion that gives the industry most profit. This is good to a degree for a healthy company, but strategy dies.

A practical example is the TM Oil Refinery which will take Oil to make either Chemicals or Petroleum. In most cases, Chemicals are produced at the expense of Petroleum. However, if low Chemical prices hurt profitability for that chain too much, the refinery will automatically transition to higher Petroleum output.

As with most things, there is a work-around using cargo production modifier events. The idea is to use such an event to cut the production of all other outputs for a particular industry to allow conversion of the one specified.

Again using the TM Oil Refinery as an example, the event could fire every week and be a basic switch between Chemical and Petroleum production. One week Chemicals would be produced, the next Petroleum, in a repeating pattern. Where there are more outputs, a more advanced rotation is needed. The trick is to make sure that any such events are tied (correct use of company and territory checks) to the map in such a way that they will not affect other sources of the cargo that need to still run at normal production levels.

---

As far as double-loading a wagon at a certain point, this cannot be done in reality but it can be done through some price simulation. I'm sorry to tell you, if you didn't know already, that RT3 is seriously bugged when it comes to price simulation events. Any increase in price is a wide open door for the game to start losing it's marbles. But using a higher price in the first place, but that is suppressed by event until the "switch to double-stack", should be a valid workaround.

[Cash on Wheels]

No, you can't double load things. The game is unfortunately locked to 8 loads maximum. All you can do is change the visuals. For example, I made bauxite cars that have 24 visible cars in the late era, but from the game's perspective there are still only 8 loads.

Is 8 cars the hard coded max? How many places would I have to look? A work around for the cargo menu slider could be some thing like 0-3-6-8-12-20-24-32-48 car loads MAX instead of 0-1-2-3-4-5-6-7-8 cl MAX.

Are there any non simulator games rail games that allow double digit cars on their trains. Everything is short!

I gave those triple baux a spin. Comments about them on the triple bauxite thread.

[Gumboots]

No, you can't double load things. The game is unfortunately locked to 8 loads maximum. All you can do is change the visuals. For example, I made bauxite cars that have 24 visible cars in the late era, but from the game's perspective there are still only 8 loads.

Is 8 cars the hard coded max?

Yes.

How many places would I have to look?

Dunno.

Are there any non simulator games rail games that allow double digit cars on their trains. Everything is short!

Dunno. But yeah freight consists are too short for good visuals in RT3, which is why I've been playing around with ideas to circumvent that.

[Just Crazy Jim]

Ok, let's say I am a bit thick. When I did exactly what the PDF said to do, my install of OSGeo4W ended up giving me a shortcut to a BAT file and no software at all. Checking the directory, I had two mostly empty folders and no executable, just a BAT file that opened the CMD window.

Seems that they changed the installation software since 2014.

I went through the process again and ended up installing a blue million things, including Python, and GRASS GIS 7.0.5, and OpenEV. I know what Python is and there is little affection between us. The other two... I've got nothin'.

[Gumboots]

I remember that when I went to install some of this DEM-related stuff I had to wing it on the installation process. Unfortunately it was so long ago that I don't remember the details. I do remember that it wasn't incredibly convoluted though. TBH I can't even remember what OSGeo4W is. IIRC I installed MicroDEM but not much else.

[Just Crazy Jim]

I've gone several rounds with this install and never got the bit that Oilcan references. I have an antique version of ArcGIS intended for the DOS 6.0/Windows 3.0 era around here somewhere... but I imagine 1) I'd need to get a floppy drive first, and 2) I figure getting a 24-year-old version of software meant to run on DOS will be an absolute transcending joy to get running on Windows 7 (I may still have PTSD from getting AutoCAD to almost, sort of work on Windows XP).... So, not gonna do it.

I'll ask my friend Liz who uses GIS software every day for work to take the bat to this when next she visits.

[Gumboots]

I got it running on W7 64 bit without much drama. I'll see if I can have another look at it this week and figure out what I did.

[Just Crazy Jim]

Well, I managed to get a height map for my chosen area, now the problem is figuring out how to get the map editor from turning it into unplayable junk.

If I have it figured right, 1 pixel in the TGA should equal about 1.5 game miles (more or less). That's a burden and a half. At 1 pixel = 1.5 in-game miles, the height exaggeration in the game makes just about everything I've tried so far into absolute crap. I'm sure there's a sweet spot on these settings... I hope....

I tried other scales, resizing the TGA, cropping, etc. But my goal is to come up with a map without 200-mile-tall ridges yet 1-mile-wide rivers... It may yet happen, geography of Wales permitting.

[Gumboots]

Yes it's tricky to get something useful.

The map scale (horizontally) depends entirely on what area you choose to crop from the DEM's. The nominal 1.5 miles per pixel, or whatever it is supposed to be, only relates to track units in the ledger. It has no relationship to the actual distances between geographical features on the map.

Getting the map heights to a useful result becomes easier as the map scale increases (ie: as real world area covered decreases) but you'll still probably have to play around with combinations of just about every map height setting available to get it near enough. It's a PITA, but it's all we have.

[Gumboots]

A bit of an update on this. From another thread:

Quote from OilCan:

Google Earth has a very different projection than the GIS maps I create for RT3 games. I tried Google Earth with the Alaska game and could not get the heightmap and images to match up. Google maps, on the otherhand, had a spot on projection which made overlaying them with an RT3 heightmap very easy.

Google changed their maps application sometime last year (maybe 2 years ago?). The newest map application uses the Google earth projection. They left a way to use the 'classical' (earlier) map application as an option. Saddly, they removed that option earlier this year.

Turns out we are once again in luck, for the moment anyway. I found a handy dodge. The USGS EarthExplorer home page has a nifty Google map on it for reference and (this is the good bit) it uses a cylindrical projection for map view and for satellite view. In other words, it is set up so that the projection will automatically match heightmaps taken from DEM's. Various overlays can be toggled on and off, so you can screengrab the area you want and match it up for latitude and longitude. It should only require a bit of horizontal and vertical scaling to make it fit the 1024x1024 demanded by RT3.

There is a bit of a catch, in that the map is inconveniently small. It would be handy if you could grab the entire area in one shot, at a fairly large scale. Turns out you can do that too, if you're a tad cunning. What I did was use Stylus to run some custom CSS in my browser. This alters the page's presentation to make it more useful. Note that it only affects presentation in your own browser. It's quite common practice to do this, and it's not malicious code at all. Anyway, the result looks like this on my monitor...

The blue square in the last shot is 1024x1024, the size required for RT3 map textures. Screengrabs will need scaling for width if you are doing a fairly wide map, but that isn't a big deal. This is going to be very handy indeed. I wish I'd figured this out before I did that Latvia map.

One thing that did occur to me is that anyone using screengrabs from Google Maps or Earth really should be polite and include some attribution. This could be done in any readme files, and added as a postscript to the scenario start dialogues. That way if anyone legally inclined does ever happen to check one of the relevant maps, at least you're trying to be nice. This tends to make people happier than the alternative of not bothering to be nice, so is generally a good idea.

Edit: I just checked more carefully, and although the projection is cylindrical it is not quite the same everywhere. It is the same everywhere horizontally, but as you go north the latitude lines get fractionally close together (by about 0.04 degrees per grid line at the "50 km" scale). This would not be a problem in many cases, but even when it was it would be easy to work around it by slicing the screengrab horizontally and scaling the slices slightly, if you were really worried about getting it as close to perfect as possible.

PS: The custom code I'm running in Stylus looks like this. The height is sized for my monitor, and can be easily adjusted to fit any other monitor. The width will automatically fit anyway.

Code: Select all

@namespace url(http://www.w3.org/1999/xhtml);

@-moz-document url("https://earthexplorer.usgs.gov/") {
  #searchCriteriaBox,
  #navbar,
  #mapDisclaimer,
  div.gm-svpc {
    display: none;
  }
  #right-col {
    position: fixed;
    z-index: 999;
    left: 0;
    right: 0;
    top: 64px;
    bottom: 0;
    margin-left: 0;
  }
  #map {
    height: 1052px;
  }

}

[Gumboots]

Tried a quick test of the idea. Test map was 1 degree East over to 17.19 degrees East, and 51.45 North down to 45.15 North. The odd dimensions are chosen because one DEM crop is as easy as another, and these proportions catch some key cities while giving equal vertical and horizontal scales. Map size is 768x448, and real life map scale is just over 1 pixels per mile (about 1.03).

I sliced multiple copies of the screenshot at the horizontal grid lines, then scaled them vertically to suit, before merging the slices into one layer and the resizing that to 1024x1024 and saving as a BMP. This was then applied to the map via bmp2gmp, with no further attempt to tidy things up. The match around the English Channel and Adriatic coasts is pretty good. It could be made a bit better without too much trouble (there are various ways to fudge this, none of which are difficult).

I imported the heightmap with 0.5 for overall and mountain height modifiers, and 0 for smoothing. Terrain seems pretty accurate. The alpine lakes from the satellite shot fit exactly where they should, and the snowy peaks appear to be in the right places too.

I've run a quick check on a few cities, and they seem to be good to go as well. Doing it this way is a lot easier than trying to tile things up from Google Earth, so I'm calling it solid proof of concept.

[RulerofRails]

Just a random thought, the colors on the Google imagery at the level that can be used for an RT3 seem very dead to me. I don't know if it's part of the replacement/combination algorthim or what? When I tried to use the bmp2gmp I ended up finding a still image and using that which required me to do lot of work on the coastlines etc. so not a good solution. I did a quick look around, not comprehensive, but it seems that a lot of the other projections with IMO better colors use cylindrical projection. Even Bing maps.

Here's a little example.

[Gumboots]

I find that any sat shots need tweaking to work with the available RT3 trees and other factors. Forests always look dark from space. RT3 waves break back from the actual ocean or lake edge (so you get some bare blue sitting around). I expect to do some adjustment of satellite shots to balance things out a bit.

I find the Google colours pretty accurate on the whole, when I check them against places I know the look of IRL. The Bing ones seem more saturated in parts, if you like that look, but I don't think they're necessarily more accurate. For example, the Red Centre of Australia is called the Red Centre because it's red. Heaps of iron oxide in the soil and sand out there, and if you fly over the middle of the country it's just rust red for hours. Google captures that colour pretty well, whereas Bing doesn't (much flatter and more faded). The darker sea in Bing isn't an issue because RT3 will put its own water surface over it, so you can't really tell what the ocean background colour is except near the shore, and it's easy to change if you want to. IMO Google tends to capture the colours near beaches better, rather than jumping directly to dark blue.

The other thing about Bing maps is that you have no idea what the projection is*, because they don't provide any grid. That means if it's out of whack a bit you'll have to fix it by trial and error. I know Google Maps doesn't use cylindrical, because when you zoom out it shows a globe, so it must be using a different projection. Bing also doesn't allow vertical and horizontal scrolling via the arrow keys, so you can't take a consistent strip in any direction. The USGS page allows you to do this.

BTW, the screenshots of the test map were taken just after sunrise. The middle of the day is quite a bit brighter.

*Edit: Decided to use my brain for a change, and did a quick search. https://en.wikipedia.org/wiki/Web_Mercator_projection

So it is a form of cylindrical projection, which is handy, but Bing still don't provide any grid references.

[RulerofRails]

You, are correct, Bing isn't a perfect source. I wasn't recommending it as a superior alternative. I just had it up when I was trying to make an illustration.

There are other sources too, also with flaws, such as:
https://s2maps.eu/
has stitching bands

https://zoom.earth
has clouds, but you can access everyday and maybe find a shot without too many clouds.

As I said I didn't look that hard, so there's probably better ones somewhere.


The saturation is a matter of taste. But that could also be adjusted.

Google does do the deserts well. However, the thing is that it's not very realistic to have a sprawling railroad in the middle of the desert. Realistically, how many maps are we going to make in the Sahara, Gobi desert, etc.?

For all intents and purposes the places where people live tend to have seasonal changes in vegetation. Whether this is natural as in a summer/winter or a wet/dry, or man-made as in crops planted/harvest etc. an average in my opinion just doesn't look right.

This is what I am meaning with Google. Obviously they aren't too concerned with this level of imagery. I'm guessing that their algorithm averages the coloration of vegetation throughout the entire year. This seems to bleed green into almost all colors where there is any vegetation. At any particular point in reality I think that if the season is right there will be darker shades of green where real vegetation is and definitely more bare ground especially in dry/winter seasons which would be more brown tones. Or maybe it's just me?