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

[AzureWings]

I've been using the 8-category precipitation map. I've internally been trying to use temperature and precipitation values rather than categories whenever possible - the input data is quantized but I've been thinking I'll have the script use configurable color profiles for temperature and precipitation (so you could swap between different input color sets and categorizations without having to alter the actual script itself), so I want the core classification logic to be agnostic of the input data categories. As it stands now my script was set up for the 8-category precipitation data input.

Tried the piecewise aridity threshold function from the Kottek et al. paper Azélor linked and everything's super humid now (ex. Australia with no B climates at all), so I'm going back over my math again.

Edit: Ah, was missing the factor of 10 applied to the threshold. New output looks a bit better on the aridity all around - still seems a shade dry maybe but I think its an improvement over the continuous-threshold version:
earthTest12.png

[Charerg]

I've been using the 8-category precipitation map. I've internally been trying to use temperature and precipitation values rather than categories whenever possible - the input data is quantized but I've been thinking I'll have the script use configurable color profiles for temperature and precipitation (so you could swap between different input color sets and categorizations without having to alter the actual script itself), so I want the core classification logic to be agnostic of the input data categories. As it stands now my script was set up for the 8-category precipitation data input.

That's definitely the best approach. My script is much more simplistic in the sense that it just goes through a long series of colour-picking operations the old fashioned way, and the actual math was done separately in Excel by Azelor. But it's a much better approach from a data processing point of view to just put the criteria for the climate groups within the script itself. So I guess your script goes through the map pixel-by-pixel, checking the value from each source map and calculating the climate type based on that?

Although I'm a bit surprised that Am is so limited if you used the 8-step maps as a data source. How did you set up the criteria for Am climates?

[Azélor]

There are steppes between the tropics in strange places.

[Charerg]

There are steppes between the tropics in strange places.

In SE Asia and Africa, yes. But those are pretty much certainly due to having data from just two months. Also, the BS in Guatemala & Honduras is far too extensive (but again, probably due to the 2-month-only nature of the source data). Mexico looks about right.

[AzureWings]

Many of the steppe areas in the tropical zones (particularly in central Africa) do seem to be an artifact; the script organizes the two temperature inputs in order of how hot to distinguish summer/winter (so that the input order or hemisphere don't matter as much), but flipping the default order for regions that have the same input temperature category makes most of those areas at least somewhat smaller except for in Eastern Brazil (even though that change to the script shouldn't really change anything). The reason for that in turn is probably the calculation for the aridity threshold, which makes me wonder what the canonical way to treat the tropical zones with low seasonal temperature variation is, since which threshold is used depends on whether the high(er)-precipitation season is considered summer or winter. For reference, changing just that order gives this result:
earthTest13.png

For the Am climates, looking at pixels that had both input temperatures > 18 °C (so all the A pixels), after ruling out Af by checking whether both precipitation inputs are > 60mm, I then check whether the lower precipitation >= (100 - (P_ann / 25)), where I compute an estimate for P_ann via (6 * P₁) + (6 * P₂). P₁ and P₂ are the mean of the min and max values for the precipitation categories of the two inputs (e.g. if input 1 is of the 100-200mm category, P₁ = 150mm and so on). A possible issue in high-precipitation cases is what I set the highest precipitation category to; I kind of eyeballed it since all I had to go off of was the category being 200mm+ and so the estimate there is actually 250mm. It's possible that P_ann is thus being misestimated and feeding Am to Aw/As, but I don't know what to base the reference precipitation for that category on instead since it lacks a maximum (and if anything I'd have thought I was overestimating the highest precipitation category and that would've made Am more common rather than less).

[Charerg]

Many of the steppe areas in the tropical zones (particularly in central Africa) do seem to be an artifact; the script organizes the two temperature inputs in order of how hot to distinguish summer/winter (so that the input order or hemisphere don't matter as much), but flipping the default order for regions that have the same input temperature category makes most of those areas at least somewhat smaller except for in Eastern Brazil (even though that change to the script shouldn't really change anything). The reason for that in turn is probably the calculation for the aridity threshold, which makes me wonder what the canonical way to treat the tropical zones with low seasonal temperature variation is, since which threshold is used depends on whether the high(er)-precipitation season is considered summer or winter. For reference, changing just that order gives this result:
earthTest13.png

For the Am climates, looking at pixels that had both input temperatures > 18 °C (so all the A pixels), after ruling out Af by checking whether both precipitation inputs are > 60mm, I then check whether the lower precipitation >= (100 - (P_ann / 25)), where I compute an estimate for P_ann via (6 * P₁) + (6 * P₂). P₁ and P₂ are the mean of the min and max values for the precipitation categories of the two inputs (e.g. if input 1 is of the 100-200mm category, P₁ = 150mm and so on). A possible issue in high-precipitation cases is what I set the highest precipitation category to; I kind of eyeballed it since all I had to go off of was the category being 200mm+ and so the estimate there is actually 250mm. It's possible that is raising P_ann too much and feeding Am to Aw/As, but I don't know what to base the reference precipitation for that category on instead since it lacks a maximum.

Usually "summer" is defined as Apr-Sept for northern hemisphere summer, and vice-versa for the southern hemisphere. If you define the seasons based on when the max. temperature occurs, you end up with a map that can provide misleading information. Consider the Ethiopian Plateau in your map: it's depicted as summer dry because it's hotter during northern hemisphere winter (which is the dry season), so the seasons are reversed relative to other areas nearby like India, which can be extremely confusing.

Regarding Am, I suspect you have the highest prec category set with a too low precipitation value. The higher the value is, the more Am will appear. As an example, if you set it up as 420 mm, any area that has the highest category of rain (and the other season is less than 60mm) will be classified as Am (since the condition will then be P_min>=0).

Btw, if you still use the 8-step precipitations, those have a 140-200 mm category as 2nd highest, so the average there should be 170 mm. I think I used 280 mm as an average for the highest category (Azelor used 300 mm, which provides similar results).

[AzureWings]

Updated the script to distinguish summer/winter more specifically, with inputs identified to be northern-hemisphere-winter and -summer respectively for temperature and precipitation; should be more technically correct although it brings back a bunch of the BS zones in the middle of tropical areas. Also raised the 'pseudo-max' used to compute the average for the top precipitation category quite a bit, which brought in a lot of Am that hadn't been present before. 420mm seemed like a huge jump over the next highest category, but then I thought about it a bit and realized I've had more than that in one month where I live.

Regarding the 8-step categories, 140-200mm is what I used in the script for the second-highest category; I just hadn't checked back with it before describing the example in my post (I just included that to try to disambiguate what I meant by P₁ and P₂.

This is what I'm looking at now:
earthTest16.png

I'm still a little unsure about the tropical zones with low seasonal temperature variation and the aridity threshold. Wouldn't the piecewise formula introduce a discontinuity at the equator, since there's a strong bias towards one season in terms of precipitation despite similar temperatures between seasons (so flipping when is considered summer/winter at the equator would add that +28 term to the aridity threshold right along the line)? Or is it just that in reality it doesn't matter since the precipitation is still so high anyways in those regions if the full year is taken into account (so it's just a difficult-to-avoid consequence of using these constraints for input data)?

[Azélor]

I don't know where you live, but I believe the maximum is 2768 mm of rain for the month of July east of Mangalore, India. That is the highest value for the month.

I'm still a little unsure about the tropical zones with low seasonal temperature variation and the aridity threshold. Wouldn't the piecewise formula introduce a discontinuity at the equator, since there's a strong bias towards one season in terms of precipitation despite similar temperatures between seasons (so flipping when is considered summer/winter at the equator would add that +28 term to the aridity threshold right along the line)? Or is it just that in reality it doesn't matter since the precipitation is still so high anyways in those regions if the full year is taken into account (so it's just a difficult-to-avoid consequence of using these constraints for input data)?

Yea, I always thought that the winter/summer distinction did not make much sense close to the equator and messes things up.
Normally, we have already discussed long time ago that the timing of the dry season matters.
Climates with dry winter need more precipitation to be considered wet than the always humid climates and the summer dry climates.
But here the winter/summer refers to temperatures only, not the precipitations.
Since the temperatures are the same, there is not winter or summer distinction.
So while there can be a dry season, it doesn't make much sense to apply the s or w threshold.
No matter when the precipitations fall, the impact will be the same.

So, I think maybe the area around the equator should use the f threshold, instead of the w or s thresholds?
Does that make sense?

It might be a good idea to try to extend this rule to all the places with little temperature variations too.

[Charerg]

Updated the script to distinguish summer/winter more specifically, with inputs identified to be northern-hemisphere-winter and -summer respectively for temperature and precipitation; should be more technically correct although it brings back a bunch of the BS zones in the middle of tropical areas. Also raised the 'pseudo-max' used to compute the average for the top precipitation category quite a bit, which brought in a lot of Am that hadn't been present before. 420mm seemed like a huge jump over the next highest category, but then I thought about it a bit and realized I've had more than that in one month where I live.

Regarding the 8-step categories, 140-200mm is what I used in the script for the second-highest category; I just hadn't checked back with it before describing the example in my post (I just included that to try to disambiguate what I meant by P₁ and P₂.

420 mm was just an example I used to demonstrate that if you use that high an average all areas covered by the highest prec category should become Am (unless they're Af). I don't actually recommend using that value . Using an average value of 280-300 mm seems to work well.

If we wanted to catch the areas that have an Am climate due to receiving more than 2500 mm annual precipitation we'd need to add a new precipitation category for areas that receive above ~450 mm during the rainy season (that would push the annual prec over the 2500 mm threshold, even if the dry season has 0 mm). An example would be Conakry, it has 5 months with close to 0 mm, but the rainfall is so extreme during the rainy season that the annual total is well above the 2500 mm, and hence it's an "automatic Am climate", despite having a very pronounced dry season.


Re: the thresholds
I think it's good to keep in mind that the primary reason that equatorial Africa is a mess is the limited data: since we have data from just Jan and Jul, only the extreme positions of the ITCZ over Africa are depicted, leaving a big data gap over the equator. Fiddling with the thresholds to remove the steppes could make other areas too humid, and ultimately the overall climate distribution would still be off in equatorial Africa.

Also, I suspect that if we're going to use just one aridity category for equatorial climates (which does make sense), it's probably better to use W (so 280+Tann*20). Otherwise the aridity threshold may be set too low. In general, I think the S (Tann*20) threshold is set deliberately "too low", since the Cs areas can include some rather arid regions. Köppen based his classification on vegetation, and "Mediterranean vegetation" roughly represented by Csa typically contains plants adapted to quite dry conditions. Some tropical BS areas are probably more verdant than the drier Csa climates in actuality.

[Azélor]

(which does make sense), it's probably better to use W (so 280+Tann*20).

But then it will be even drier.
I know the problem mostly comes from using 2 months only.
For example Accra, Ghana : the wettest month is in June but we use the data for July (less than a third of the precipitations of June). Therefore it appears a lot drier that it is in reality.

But it is not really a problem since when mapping the precipitations, Accra should be located right under the ITCZ.
Maybe we should<nt bother too much about it.
The map generated with the script will always be "wrong" as long as we use real world data.
That is ok as long as the tutorial fixes these problems by slightly altering the precipitations.