The Köppen–Geiger climate classification made simpler (I hope so)

[Azélor]

Btw, I think it might be a good idea to put a link to the latest version of the GIMP script in the OP, so at least people know that there's one available, since the thread has grown so long that it would be a pretty heroic undertaking for a potential tutorial-user to read through all 37 of the pages .

Will do

Have you thought about Universe Sandbox ?
Of course it's not a NASA soft and the climate aspect still seems to be underdeveloped.
But they have hired this year an "Astrophysicist, Climate & Simulation Developer" and their incoming Planet Grid could improve the climate simulation.
Mays be i'm too optimistic, but is there nothing you could do with this soft ? (i do not own it btw)

I just have the old version of the software, I was not aware that they added climate in the newest version.

[Pixie]

I'm neither a software developer or a climatologist, but as a science teacher/communicator specialized in physics, I would love to contribute to the development of an automated tool.

You know, I think you are really on to something. I helped with the kickstart but as of now, I have less time and you guys have just sprinted away from me. I can follow your discussions but not pitch in anything useful. Still, if/when it comes to rewrite those instructions for precipitation and temperature maps (or something like that) - count me in.

[AzureWings]

Speaking of said script, I've made the Python script available on Github: https://github.com/PHarvey7/speculative-koppen. It's not a script for GIMP or Photoshop directly; it's a command-line tool that just takes image files as input (all my testing has been on .pngs) and outputs a new one (possibly less convenient than an in-editor script, but also potentially more flexible). The directions and some of the sample files describe a couple simple formats for raw text files you can make and pass as additional arguments to specify custom input and output color profiles - e.g. what colors the script outputs for each climate category, and what colors your input data images use and what those colors mean.

Right now the input images must be RGB with no alpha channel, though my next steps with the script at some point are to make it more flexible in that regard and be able to take RGBA, etc. Currently the input color profile should include a color for ocean that the script will treat as such, in lieu of having the ocean on an alpha channel. Running the script also requires Python 3 and Pillow installed (for Python image file operations).

[Kalium]

OOoh... I'm tempted to give that script a go. Will need to redraw my rain/temp maps but I'd like to see how it stands up against my hand done climates. If I get any interesting results I'll be sure to let you know.

[AzureWings]

So I was running through the whole process for a world I threw together just for this (actually just to make source data for something else I was going to try, so it's done a bit hastily and shoddily, admittedly). I was finding the first step of assigning temperature categories (the "paint by isotherm" stage, as one might call it) a bit tedious, and decided to throw together another script similar to the other Python command-line one for it. It takes the result of the previous phases (elevation map and the temperature/current influence zone maps) and outputs July/January temperature maps. The resulting output obviously needs a fair bit of manual work still to make better transitions (witness the amazing sheer horizontal isotherm lines!), but that's kind of a step you perform anyways. The idea is this script does a lot of otherwise-busywork to give you a further-ahead starting point to work from for assigning temperatures.

With the current testing, as I didn't have Earth data in a convenient format immediately on hand, I was tossing these in:

Elevation input
chordRasterHeightsFixed.png

January temperature influence zones
chordRasterInfluencesJan.png

July temperature influence zones
chordRasterInfluencesJul.png

And was generating these as output:

January temperature map
chordTempGenTest1NW.png

July temperature map
chordTempGenTest1NS.png

Obviously there's still a long ways to go on the temperature maps themselves - but does the "suggested temperatures"/"prefill" functionality this tends towards seem like something that could be worthwhile or is it probably better to just start from scratch than to work by hand from this as a starting point? If it does seem like it'd be useful to people I'll toss this script up in the same Github repository after some more tweaks and cleanup.

[Charerg]

I guess it could be useful for those users too lazy to create those maps manually . Personally I'd suggest just starting from scratch, but it doesn't hurt to have options available (and who knows, maybe it could become really solid with enough tinkering).

But without the latitude lines visible it's hard to judge how closely the generated temp maps follow the guidelines in the temperature section.

[Azélor]

It might be useful, although mapping the temperatures is probably my favourite step.

I'd just like to point out about the temperature inversion Chareng and I talked about a while back. If Antarctica was a sea level, temperatures could be warmer.

[AzureWings]

All the script does at present is do the basic isotherm-per-influence-type placement and then apply elevation adjustments, although I do have a few ideas on how it could be improved further. It doesn't place any of the extreme temperatures (very/severely hot or deadly cold outside of elevation adjustments) currently. I probably should remember to specify that while for the climate script the only thing that matters for projection is that the inputs all use the same one the temperature script needs an equirectangular one, since it directly pulls latitude from the pixel location in the image.

With a quick lat/long overlay those outputs I mentioned before are here (the small lat lines are 5° increments, although they're a couple pixels off in some places).

'January'
chordTempGenTest1NWwOverlay.png

'July'
chordTempGenTest1NSwOverlay.png

One thing I've already tried out as an improvement is internally giving the 'base' temperatures as interpolated between the edges of the category based on the latitude (e.g. a location with no special current influences at 50°N in summer being warmer than a similar location at 65°N in summer, even though the guide puts them both at peach) instead of applying a flat value to all the temperatures in that zone. The result produced doesn't really seem better (compared to the output I've posted) in terms of the discontinuities, although intuitively it seems like it should be; elevated regions do seem to get more continuity within themselves that way, although it can result in 1000m elevated areas being more than one temperature category removed from adjacent lower-elevation zones. One advantage using a script can give is using a continuous space for temperatures internally. I might try and see how the temperatures turn out if after applying the base isotherm and elevation changes I run a small localized average across all the local temperature values as a little bit of a 'smoothing' effect. The horizontal isotherm lines are probably going to be here to stay, but places with multi-category deltas between adjacent areas should benefit.

How continuous/linear does the decrease of temperature with increasing elevation tend to be? Since the script can work on a continuous space more easily than working by hand I could have it take smaller elevation categories (500m and such) into account if they're present into the input data.

Regarding the temperature inversion, I recall reading that discussion. It's definitely something I could look into adding, although again it'd be done in a relatively formulaic fashion.

[Azélor]

How continuous/linear does the decrease of temperature with increasing elevation tend to be? Since the script can work on a continuous space more easily than working by hand I could have it take smaller elevation categories (500m and such) into account if they're present into the input data.

To my understanding, moisture is one of the most important factor influencing the lapse rate (how fast temperatures cool down with altitude). It's higher when it's dry.
Also, under certain conditions like with very cold temperatures, the lapse rate is inverted: meaning the lowland is colder than the surrounding mountains.

[Charerg]

As Azelor noted, the lapse rate varies a lot. The drier the air, the greater the lapse rate. With relatively moist air and relatively low elevation (0 to 3 km), the lapse is maybe 4-5 °C/km typically, but it can go up to 6-7 °C/km if the air is dry. There is also a general tendency for the lapse rate to increase as elevation increases (presumably because the air becomes drier).

The average lapse (used by Azelor in the temp guideline) is 7.5 6.5 °C/km, but that applies to the whole troposphere from 0 to 11 km. In the lower levels of the troposphere (say, 0 to 5 km) the lapse rate is typically below the average.