[GeoRealism] The two core BiomeInfo files

[Laskaris]

I have spoken with Laskaris about this both in PM and in some of these discussions. If all goes well he won't have nearly the amount of work in order to accomplish this. Our goal (assuming he agrees with my proposal I recently sent him) is to use his map to test and perfect the climate engine, thus having the engine create the C2C version of the Earth map. If all goes well, the only changes that will need to be made to the resulting map are placements that arise from the random element in the engine (i.e. placement of specific vegetation and bonuses).

I don't mean to be a naysayer, but I'm not sure that any climate engine we can come up with could model all the local climates to the leve of detail that my 232 x 112 plot map has. Even with the Global Climate Models that run on supercomputers, they have trouble getting the small-scale, local climates right. Granted, we aren't trying to program an actual Global Climate Model, with vertical atmospheric cells, deep ocean currents and so on, but something more simple and straightforward. Still, expecting the climate engine to create an accurate model of Earth, in all the details, is probably too ambitious a goal.

I agree that using my map to make the engine as good as we can make it might be a good idea, but this raises another issue: the question of map projections. I use a cylindrical equal-area projection for my Gigantic Accurate Earth Map, with standard parallels at 37.3 degrees north and south of the equator. I think there is a lot to be said for using equal-area projections of a planetary surface in Civilization. Cities and the plots they occupy are in many ways the core of the game, so depicting landmasses with their accurate areas is important. Distortions of distance, on the other hand, are not that bad because distance is rather abstracted in Civilization, anyway (armies that take 20 years to reach their destination? yeah right!).

The equal-area projection is a pretty complex one, though, and might not be the best one for the various GeoRealism engines to work on. So, assuming that you want to use an equal-area projection as the final result, you have two choices:

1) Let the GeoRealism engines work with maps that are already in an equal-area projection, meaning that the lines of latitude are not evenly spaced - there is a large space between the equator and 10 degrees latitude, but a much smaller one between 80 degrees latitude and the pole, and so forth:

Or, 2) Let the GeoRealism engine work an another map projection that is more well-suited for straightforward mathematics, like an equirectangular projection where all the latitudes are evenly spaced out, and then convert the map into an equal-area projection in a separate operation afterwards.

And if you don't want to use an equal-area projection at all, then 3) My map is of no use to you, anyway.

 

[primem0ver]

Still, expecting the climate engine to create an accurate model of Earth, in all the details, is probably too ambitious a goal.

Perfection may be impossible. And certainly reproducing every plot accurately to what exists on earth is impossible. Like I said, their is a random element that is used because calculating specific vegetation for a specific plot would not necessarily be possible nor necessary. I am simply point out that I believe that the climate of plots on the map can be fairly if not very accurately calculated. If that is true then you will only need to modify vegetations, bonuses, and the occasional climate.

I agree that using my map to make the engine as good as we can make it might be a good idea, but this raises another issue: the question of map projections. I use a cylindrical equal-area projection for my Gigantic Accurate Earth Map, with standard parallels at 37.3 degrees north and south of the equator. I think there is a lot to be said for using equal-area projections of a planetary surface in Civilization. Cities and the plots they occupy are in many ways the core of the game, so depicting landmasses with their accurate areas is important. Distortions of distance, on the other hand, are not that bad because distance is rather abstracted in Civilization, anyway (armies that take 20 years to reach their destination? yeah right!).

The equal-area projection is a pretty complex one, though, and might not be the best one for the various GeoRealism engines to work on. So, assuming that you want to use an equal-area projection as the final result, you have two choices:

1) Let the GeoRealism engines work with maps that are already in an equal-area projection... (and so forth)

There are only three things that using equal area will affect: calculating relative humidity, determining plate size, and calculating the affect of crust deformation. I will consider it, especially if it helps the engine be more accurate.

 

[Laskaris]

There are only three things that using equal area will affect: calculating relative humidity, determining plate size, and calculating the affect of crust deformation. I will consider it, especially if it helps the engine be more accurate.

I don't think I made the gist of my question clear. The issue I was trying to raise was that of the latitudes.

On a map using an equirectangular projection, the latitudes are evently spaced out. So, if you had a map that was, say, 118 squares high, the equator would be at y=59. 40 degrees northern latitude would be at about y=85. 80 degrees northern latitude would be at about y=112.

An equal-area projection like the one I used for my Gigantic Accurate Earth Map has distortions of north-south distances. It stretches north-south distances near the equator, and squashes them near the poles. That's how it gets the accurate representation of area. As a consequence, the latitudes are not evenly spaced out. On my equal-area map of 118 squares height, the equator would still be at y=59, but 40 degrees northern latitude would be at about y=95, and 80 degrees northern latitude would be almost at the upper edge of the map, around y=116.

So, on an equirectangular map, the latitudes are nicely and evenly spaced out along the y axis, while on an equal area map, there are distortions. Obviously, it makes a great deal of difference for the engine, because you have to make the climate engine take into account which latitude is where on the map, exactly.

I hope I managed to phrase my concern more clearly now.

 

[Koshling]

I wonder if anyone has ever constructed an equal luminosity (solar) map

 

[Laskaris]

I wonder if anyone has ever constructed an equal luminosity (solar) map

That would be easy. The equatorial circumference of the Sun is about 109 times that of Earth, so to keep the same scale as my 232 squares wide Earth map, that Sun map would have to be 25288 x 12644 squares. No problem with viewports and a couple of .dll rewrites! And we just fill it all up with a new "Sun Surface" terrain.

It would probably be a bit monotonous to play on, though.

 

[Koshling]

That would be easy. The equatorial circumference of the Sun is about 109 times that of Earth, so to keep the same scale as my 232 squares wide Earth map, that Sun map would have to be 25288 x 12644 squares. No problem with viewports and a couple of .dll rewrites! And we just fill it all up with a new "Sun Surface" terrain.

It would probably be a bit monotonous to play on, though.

Not what I meant. I went equal (incoming solar) radiation projection of the earth's surface. Would probably be boringly similar to Mercator though.

 

[Laskaris]

Not what I meant. I went equal (incoming solar) radiation projection of the earth's surface. Would probably be boringly similar to Mercator though.

I have no idea what you mean by "equal (incoming solar) radiation projection of the earth's surface", or why it would be similar to Mercator. Care to elaborate?

 

[primem0ver]

Not what I meant. I went equal (incoming solar) radiation projection of the earth's surface. Would probably be boringly similar to Mercator though.

I am pretty sure he means that the further north you go, the more spread out the sunlight is. It would be similar to your equal area projection (on earth). It would be the inverse relationship if mapped on the sun (larger squares at the top).

@Laskaris
Ok... you are right, I was addressing area (as you said) more than the location of actual latitude lines. That does make a bit of a difference. I will have to think about that one. I also would like to hear what other people's preference is.

@ EVERYONE
What do you think of Laskaris' note about latitudes being evenly spaced (easier to deal with in gameplay) versus decreasing distance between them as we head away from the equator (more accurate maps)?

 

[ls612]

I am pretty sure he means that the further north you go, the more spread out the sunlight is. It would be similar to your equal area projection (on earth). It would be the inverse relationship if mapped on the sun (larger squares at the top).

@Laskaris
Ok... you are right, I was addressing area (as you said) more than the location of actual latitude lines. That does make a bit of a difference. I will have to think about that one. I also would like to hear what other people's preference is.

@ EVERYONE
What do you think of Laskaris' note about latitudes being evenly spaced (easier to deal with in gameplay) versus decreasing distance between them as we head away from the equator (more accurate maps)?

I vote for easier gameplay as it seems to be a rather small realism sacrifice.

 

[Laskaris]

@ EVERYONE
What do you think of Laskaris' note about latitudes being evenly spaced (easier to deal with in gameplay) versus decreasing distance between them as we head away from the equator (more accurate maps)?

I vote for easier gameplay as it seems to be a rather small realism sacrifice.

I don't see why gameplay would be in any way easier on an equirectangular map than on an equal-area map. It does not really affect gameplay as such at all. The only difference would be in the internal workings of the GeoRealism engine that generates the maps.

I'm still not sure that I am making the issue, in regards to the climate engine, clear. I'll try again:

Latitude is one of the major factors in determining climate. The tropcal zone extends from the equator to 23.5 degrees latitude, the temperate zone from there to 66.5 degrees, beyond which is the polar zone... This kind of stuff.

Now, different kinds of map projections have these latitudes at different places on the map. For instance, this is an equirectangular projection, where the latitudes are evently spaced out. Look at the white lines:

This second map is an equal-area map, where north-south distances are distorted in order to get an accurate represenation of the areas of the landmasses and oceans. As you can see from the white lines at every 15 degrees latitude here, the latitudes are farther apart around the equator and get closer and closer together towards the poles:

For the climate engine to take latitude into account and place climates accordingly, it obviously has to know where on the map 10 degrees, 20 degrees, 30 degrees and so on latitude are. This differs between an equirectangular projection and an equal-area projection. So, depending on which one you want to use, you will have to program the climate engine accordingly.

This is what I was trying to point out. What projection we use makes a difference for how we will have to program the climate engine. It doesn't make a difference in gameplay for the players, except that it produces slightly different kinds of maps.

One advantage of using an equal-area projection, i.e. of representing all the landmasses with their accurate areas relative to each other, is that you get the polar regions with their accurate size. On other map projections, the polar regions are bigger than they should be, so you have more useless, frosty terrain in the north and south.

All cylindrical maps are inaccurate in one way or another - it's impossible to represent a planet's surface on a rectangle without some kind of distortion. The only option we have available is to decide what aspect of the planet's surface we want to distort. North-south distances, and with them continental shape (note that east-west distances are distorted on any cylindrical map, anyway)? Or area?

Equirectangular map:
- east-west distances are distorted
- no distortion of north-south distances
- no accurate representation of area
- area of tropical region is smaller than it should be
- area or polar regions is bigger than it should be

Equal-area map:
- east-west distances are distorted
- north-south distances are distorted
- accurate representation of area
- area of tropical region is accurate (i.e. bigger than on an equirectangular map)
- area or polar regions is accurate (i.e. smaller than on an equirectangular map)

Personally, I think there is a lot to be said for using equal-area maps in Civilization. Cities and the plots they occupy are in many ways the core of the game, so accurate representation of landmass areas is important. Distortions of distance, on the other hand, are not as bad in my view, because distance is represented rather abstractly, anyway (armies taking 20 years to reach their destination? yeah right!).

Whichever projection we end up choosing, though, the issue I was trying to raise is that it will have an effect on how we have to program the climate engine, because the latitude lines are on different places on the map depending on the projection.

 

[primem0ver]

I'm still not sure that I am making the issue, in regards to the climate engine, clear. I'll try again:

No... it was as clear as it needed to be. I got it the second time around (first time with the map). Changing the latitude to reflect whether equal area parallels or evenly spaced parallels are used will have a major impact on where climates are placed. I get that. We can probably use a scenario variable to control which is used within the engine. If a scenario is loaded using equal area, then the climate calculations will adjust latitude to match. If not, then we use the evenly spaced latitudes.

I don't see why gameplay would be in any way easier on an equirectangular map than on an equal-area map. It does not really affect gameplay as such at all.

The difference is that it is easier to comprehend and guess what latitude you are at. Understanding where you are in the world will come in handy... especially if we start adding events that the Genetic Era Mod had in them (that are very historically significant) such as getting "lost in the doldrums" and freezing to death in the arctic north.

NOTE: However Laskaris, it is good that you summed up the good and the bads for us. Thanks.

I had another thought too. We can give the player the choice of which they would rather use (i.e. equal area or equal distance) in the GeoRealism options panel that I mention in the main thread.

 

[Thunderbrd]

I had another thought too. We can give the player the choice of which they would rather use (i.e. equal area or equal distance) in the GeoRealism options panel that I mention in the main thread.

Great idea! I look at both and while I like the look of the second FAR better, on a game map that'd have so much arctic territories it'd be ridiculous for play!

 

[Laskaris]

@ primem0ver: Okay, great! I was just confused by your remark that gameplay would be "easier" on an equirectangular map. I see now what you mean: on an equirectangular map, it is easier to tell by instinct where, exactly, the latitudes are.

I think that giving a player the choice between an equirectangular and an equal-area map would be by far the best option. It shouldn't be a big amount of programming work for the engine, either, because the conversion from equirectangular to equal-area is pretty straightforward mathematically.

 

[DRJ]

Great to see climate and vegetation included, had some brainstorming about that half a year ago, then my pc broke down and my old pc couldn't handle C2C. But now I am back, testing it asap

 

[Laskaris]

Update: It took a little while, but I think I've figured out the best way to make a program determine the Köppen climate type of a tile. It's quite different from what we have so far, but it's elegant and precise and it's going to work. I believe that this is how a scientific climate model program would do it as well (I read some papers on this, which gave me the idea).

Basically, what you need is a program that goes through a series of pre-set steps, along a decision tree (with "yes" / "no" decisions) until it has determined the climate type of the tile. For some climate types, this goes very quickly, while for others, it takes longer because the tile has to be "tested" for more different properties and thus more different calculations have to be made.

I'm going to write down the beginning of the process for you, in plain natural language, so you get an idea of how this is going to work:

Spoiler :

As a starting dataset for the tile, we need the precipitation and mean temperature of the tile for every month of the year.

Step (1): Determine the warmest month of the year. Then, go to Step (2).

Step (2): Is the mean temperature of the warmest month of the year below 10° C? If yes, go to Step (3). If no, go to Step (4).

Step (3): Is the mean temperature of the warmest month of the year below 0° C? If yes, the climate type is EF (ice cap). Finished! If no, the climate type is ET (tundra). Finished!

Step (4): Determine seasonality of percipitation. Is the climate summer-dry, winter-dry, or non-seasonal? Once this is determined, go to Step (5).

Step (5): Determine the aridity threshold. The exact formula varies slightly, depending on whether the climate was determined as summer-dry, winter-dry of non-seasonal in Step (4). Once aridity threshold is determined, go to Step (6).

Step (6): Is the annual precipitation of the tile below the aridity threshold x 2? If yes, go to Step (7). If no, go to Step (8).

Step (7): Is the annual precipitation of the tile below the aridity threshold x 1? If yes, the climate type is BW (desert). Finished! If no, the climate type is BS (Semi-arid). Finished!

Step (8): Determine the coldest month of the year. Then, go to Step (9).

Step (9): Is the mean temperature of the coldest month of the year above 18° C? If yes...

And so on and so forth!

primem0ver, let me know what you think! And then, we can go to work on the details.

 

[primem0ver]

Update: It took a little while, but I think I've figured out the best way to make a program determine the Köppen climate type of a tile. It's quite different from what we have so far, but it's elegant and precise and it's going to work. I believe that this is how a scientific climate model program would do it as well (I read some papers on this, which gave me the idea).

Basically, what you need is a program that goes through a series of pre-set steps, along a decision tree (with "yes" / "no" decisions) until it has determined the climate type of the tile. For some climate types, this goes very quickly, while for others, it takes longer because the tile has to be "tested" for more different properties and thus more different calculations have to be made...

primem0ver, let me know what you think! And then, we can go to work on the details.

Wow! That makes it easy. I will just need to know each algorithm/calculation you mention.

UPDATE: I am currently rewriting some of the code because I found a way to work continental air masses into the picture/calculations in a way that isn't just plain guess work.

 

[Laskaris]

Okay, primem0ver, here we go. If you have any questions about any of the steps or calculations, let me know.

Original input:
Monthly precipitation data and monthly mean temperature data, plus info whether the tile is located on the northern or southern hemisphere.

Step (1): Determine the warmest month, then check: is the mean temperature of the warmest month less than 10°C? If yes, go to Step (2). If no, go to Step (4).

Step (2): Determine the total yearly precipitation, then check: is the total yearly precipitation less than 125 mm? If yes, the climate is polar desert (POLAR_DESERT). Finished! If no, go to Step (3).

Step (3): Check: is the mean temperature of the warmest month less than 0°C? If yes, the climate is ice cap (ICE_CAP) Finished! If no, the climate is tundra (TUNDRA). Finished!

Step (4): Calculate yearly mean temperature T. Calculate the percentage Pw of the precipitation which falls during the six winter months (October through March if the tile is on the northern hemisphere, April through September if the tile is on the southern hemisphere). Calculate the aridity threshold A: A=2.3*T-0.64*Pw+41. Calculate the total yearly precipitation of the tile. Check: is the total yearly precipitation lower than the aridity threshold A? If yes, go to Step (5). If no, go to Step (8).

Step (5): Check: is the total yearly precipitation lower than half the aridity threshold (0.5*A)? If yes, go to Step (6). If no, go to Step (7).

Step (6): Determine the number of months with a mean temperature of 10°C or more. Then check: if the number of months with a mean temperature of 10°C or more is 8-12, the climate is hot arid (HOT_ARID). Finished! If it is 1-7, the climate is winter-cold arid (WINTERCOLD_ARID). Finished!

Step (7): Determine the number of months with a mean temperature of 10°C or more. Then check: if the number of months with a mean temperature of 10°C ore more is 8-12, the climate is hot semiarid (HOT_SEMIARID). Finished! If it is 1-7, the climate is winter-cold semiarid (WINTERCOLD_SEMIARID). Finished!

Step (8): Determine the coldest month, then check: is the mean temperature of the coldest month more than 18°C? If yes, go to Step (9). If no, go to Step (11).

Step (9): Determine the number of months with 60 mm or more precipitation. Then check: if the number of months with 60 mm or more precipitation is 10-12, the climate is tropical humid (TROPICAL_HUMID). Finished! If the number of months with 60 mm or more precipitation is 0-9, go to Step (10).

Step (10): Check: is the precipitation of the driest month bigger than (2500 mm - total yearly precipitation) / 25? If yes, the climate is tropical monsoon (TROPICAL_MONSOON). Finished! If no, the climate is tropical wet-dry (TROPICAL_WETDRY). Finished!

Step (11): Determine the number of months with a mean temperature of 10°C or more. Check: if the number of months with a mean temperature of 10°C or more is 8-12, go to Step (12). If the number is 4-7, go to Step (16). If the number is 1-3, go to Step (17).

Step (12): Determine the precipitation of the wettest summer month Pswet (April through September if the tile is on the northern hemisphere, October through March if the tile is on the southern hemisphere). Determine the precipitation of the driest winter month Pwdry (October through March if the tile is on the northern hemisphere, April through September if the tile is on the southern hemisphere). Check: is Pswet greater than 10*Pwdry? If yes, the climate is subtropical winter-dry (SUBTROPICAL_WINTERDRY). Finished! If no, go to Step (13).

Step (13): Determine the precipitation of the driest summer month Psdry (April through September if the tile is on the northern hemisphere, October through March if the tile is on the southern hemisphere). Check: is the precipitation of the driest summer month Psdry lower than 30 mm? If yes, go to Step (14). If no, the climate is subtropical humid (SUBTROPICAL_HUMID). Finished!

Step (14): Determine the precipitation of the wettest winter month Pwwet (October through March if the tile is on the northern hemisphere, April through September if the tile is on the southern hemisphere). Check: is Pwwet greater than 3*Psdry? If yes, go to Step (15). If no, the climate is subtropical humid (SUBTROPICAL_HUMID). Finished!

Step (15): Check: is the total yearly precipitation of the tile (which was already calculated as part of Step (4)) 890 mm or smaller? If yes, the climate is subtropical summer-dry (SUBTROPICAL_SUMMERDRY). Finished! If no, the climate is subtropical humid (SUBTROPICAL_HUMID). Finished!

Step (16): Check: does the coldest month (which was already determined in Step (8)) have a mean temperature of 0°C or more? If yes, the climate is temperate oceanic (TEMPERATE_OCEANIC). Finished! If no, the climate is temperate continental (TEMPERATE_CONTINENTAL). Finished!

Step (17): Check: does the coldest month (which was already determined in Step (8)) have a mean temperature of -10°C or more? If yes, the climate is sub-arctic oceanic (SUBARCTIC_OCEANIC). Finished! If no, the climate is sub-arctic continental (SUBARCTIC_CONTINENTAL). Finished!

 

[primem0ver]

@Laskaris

That is quite a set of steps. Its OK though. It would probably be nearly as my original plan. It would simply involve different tags.

I am going to try and boil these rules down to a set of some new XML tags and programming logic. I would still like you to fill in the stats on the biomes file that I sent you. I will then either take care of the new tags myself or hand them over to you.

 

[Laskaris]

That is quite a set of steps. Its OK though.

A fair bit of work to program, yeah, but I'm positive that it will work very nicely in practice. Mind you, the engine doesn't have to go through all the steps for every tile. The beauty of the system is that it only goes through as many steps as it needs to determine the climate type for a tile. If the tile is polar desert, that takes only 2 steps. If it is tropical humid, that takes 4 steps to determine. The longest process is for subtropical summer-dry, which takes 8 steps to determine.

I would still like you to fill in the stats on the biomes file that I sent you.

The problem is with the dynamic values. For instance, Köppen uses an aridity threshold to determine where there is a desert climate, and that aridity threshold (of mm precipitation per year) varies with the mean temperature and with the percentage of rain during the colder six months. There isn't any way to model that simply with a fixed "MinPrecipitation" tag.

I can write some stats in the biome files you sent me, but the results definitely won't be as accurate as with the system I outlined above. Anyway, I'll get to work on it and send it to you.

 

[primem0ver]

The problem is with the dynamic values. For instance, Köppen uses an aridity threshold to determine where there is a desert climate, and that aridity threshold (of mm precipitation per year) varies with the mean temperature and with the percentage of rain during the colder six months. There isn't any way to model that simply with a fixed "MinPrecipitation" tag.

I can write some stats in the biome files you sent me, but the results definitely won't be as accurate as with the system I outlined above. Anyway, I'll get to work on it and send it to you.

That is why I need to make some more tags. Those tags will help us know what to do with the data when it comes to the engine. We still need the data for most places.