Page 39 of 61 FirstFirst ... 2935363738394041424349 ... LastLast
Results 381 to 390 of 608

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

  1. #381

    Default

    Azure, can I ask what your method was for placing the temperature influence zones as it appears in the code? Ever since you automated the temperature placement, I’ve been mulling over how one could create a standalone program/script for the entire process, but conceptually I’ve been having problems figuring out how such a thing would recognize the placement of pixels relative to their placement on their continent (coast, interior, etc.), becauze that would be crucial for placing/generating pressure zones.

  2. #382
    Guild Grand Master Azélor's Avatar
    Join Date
    Jul 2008
    Location
    Québec
    Posts
    3,363

    Default

    Quote Originally Posted by Charerg View Post
    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.
    I think the driest lapse rate is close to 10°C/km.

  3. #383

    Default

    As of right now the temperature influence zones are part of the input - that is, those maps are produced by hand in accordance with step 5-1 of Azélor's tutorial steps linked in the first post of this thread. The script I'm working on for placing temperatures takes the elevation map and two influence maps as input (one for each seasonal extreme). I am making it configurable so you could define more types of temperature influence zones with their own isotherm tables if you wanted, but placing those zones in the input data is still left up to the user in the current formation of the script.

    That said, I did a little thinking about how one might implement other steps, although building a good model would be a lot more complicated for some of them (like generating wind patterns). If I were to try automating the temperature influence zones multiple steps end up tied together as what I'd want for input regarding wind directions (a pixel-by-pixel vector field) would be rather hard to produce by hand itself.

    That said, the specific case of recognizing a pixel's distance from the coast wouldn't be all that hard to implement in principle, although I'm not sure how the running time would end up working out since the simplest approach I can think of is a graph traversal of all the land pixels in the image. At the base level you could just build a shortest-path tree (like with common versions of Dijkstra's algorithm) after framing the problem a certain way - do one pass through all the pixels to collect a list of pixels directly adjacent to ocean pixels, and then just build the shortest-path tree from the initial set of these (treat all the immediate coastal pixels as a single starting graph node) and mark each pixel with its 'shortest-path cost' (i.e. distance to nearest coastline). You'd want to have nonuniform edge weights between pixels to handle projection distortions in the input image - if you were using an equirectangular input for instance north/south pixel boundaries would all have the same edge weights but east/west ones would vary with latitude (and there'd be an edge case regarding the fact that the east/west edge weight becomes 0 at 90°, though really that just makes all the 90° pixels into a single node like the starting one was). Implementation details aside this would feasibly give you a 'how far from coast' value for every pixel though.

    If you wanted to find, other 'relative locations on a landmass', say, pixels on a continent's west coast, you could use similar approaches - an initial pass to collect pixels immediately to the east of oceanic pixels followed by a depth-limited graph traversal to collect connected land pixels within a certain distance of those. If you wanted to handle things on the scale of metrics applied to individual landmasses - say, find pixels on a landmass only above a certain size - you could initially go through and do a union-find to produce a set of pixel values with each pixel given an identifier to say what distinct landmass it is a part of, possibly also with a reverse index from landmass ID to its component pixels (and the latter would make it really easy to see how big different landmasses are). You could combine this with the 'how far from coast' value mentioned above to filter out long, thin landmasses and find only those landmasses with continental-scale impact, then perform further checks on that (might be useful if trying to figure out what landmasses would block currents more strongly as opposed to say island chains).

    Ultimately there a lot of ways to construct metrics of useful information that isn't immediately available to a program just from the raw input image - but the question becomes how long you're willing to have the program take to run. As is the temperature script right now is just basically a set of lookup tables and it only makes one pass over the input image (which is probably going to change soon incidentally), and while I haven't done much work to optimize its performance it already takes 5-10 seconds on an about 2000x1000 input image, which isn't all that big.
    Last edited by AzureWings; 03-15-2018 at 01:07 PM. Reason: Clarity regarding graph nodes

  4. #384
    Guild Artisan Charerg's Avatar
    Join Date
    Feb 2015
    Location
    Finland
    Posts
    525

    Default

    Quote Originally Posted by Azélor View Post
    I think the driest lapse rate is close to 10°C/km.
    If the air is absolutely dry it's ~10 °C/km, but that is pretty much never the case close to sea level. Maybe above 4-5 km the lapse rate could drop that low, but overall I think it's very rare for the lapse to be that drastic in the lower troposphere.

  5. #385

    Default

    Azure, I'm incredibly impressed not only with how well-thought out your approach to this is but how much our minds are in agreement. A pixel-by-pixel vector map is exactly what I had thought of for mapping winds. Then, you would only need to add a "natural wind" vector map with one representing the pressure zones to produce a map of the resultant winds. It would be then fairly simple to model what moisture is carried via the winds, perhaps having a pixel object that holds various values for wind direction, wind strength, amount of moisture carried, etc., to generate the (rough) precipitation map.

    Your suggestion to use a shortest-path tree is far better and more efficient than what I had been thinking of (finding the distances to all coasts for each pixel) to determine what pixels lie within the interior. As you say, using those values combined with the number of pixels per land mass would make it very easy to filter out landmasses of certain sizes and distinguish island chains from actual continents. The only remaining issue I can see with that is how to approach a North America/South America (or even Africa/Asia) situation where two continents are connected via a thin land bridge?

    Personally, I'm not too concerned with run time. The initial sweeps of "data collection" from the input sources to build the overarching data structures would take the longest I would imagine, depending on the image size. To generate a full albeit basic climate model I'd be willing to wait even a few minutes, but I think that would be a very upper limit. With optimization, I'm sure it would take at most a few dozen seconds, or at least that would be my goal. I'm going to start fiddling around with this to see what I can get.
    Last edited by antillies; 03-15-2018 at 05:21 PM. Reason: Added third paragraph

  6. #386
    Guild Grand Master Azélor's Avatar
    Join Date
    Jul 2008
    Location
    Québec
    Posts
    3,363

    Default

    What is a A pixel-by-pixel vector map ? each direction would have a different colour?

    a pixel object that holds various values for wind direction, wind strength, amount of moisture carried, etc., to generate the (rough) precipitation map.
    That is doable, but the maximum value would be 255. With 2 degrees per pixel instead of one, it's still precise enough.

  7. #387

    Default

    Quote Originally Posted by Azélor View Post
    What is a A pixel-by-pixel vector map ?.
    My conception of it is not that the vector map itself would be represented by pixels but that the map (which could be any array- or table-like data structure, or even a collection of objects) would have a vector associated with each pixel. A vector in this case is a X and Y value between 1 and -1 that represents a specific direction in relation to a Cartesian plane (i.e. +Y is upwards on a graph, -Y is downward, +X is to the right, and -X is to the left). (0,1) would then be a vector pointing directly "north"/in the +Y direction. This is extremely useful for representing wind direction since vectors give us a full 360 degrees to work with. The best thing about vectors is that they can be combined to give resultant vectors (i.e. Vector A + Vector B = Vector C), so applying a force (i.e. pressure) to a given vector representing a wind would be a simple calculation.

    In regards to "pixel objects" (and here my idea for implementation may differ from Azure's), I meant more that when the data from the input images would be digested, every pixel would have a Python object associated with it that would contain relevant information for that specific place on the map. That could include elevation, wind direction, wind strength, moisture level, its XY coordinate location on the map, if it falls on the coast or the interior, how far away from the coast is it, etc.. This may not be the most efficient means to store that information but it would be a decent place to start to keep things organized, at least for me. That way, when the program begins to make the various other maps (wind, current, temperature zone, rainfall, etc.), it can call upon any information stored within that object when it is looking at any given pixel.
    Attached Images Attached Images
    Last edited by antillies; 03-15-2018 at 06:57 PM. Reason: Added some images for clarification.

  8. #388
    Guild Grand Master Azélor's Avatar
    Join Date
    Jul 2008
    Location
    Québec
    Posts
    3,363

    Default

    So you would need to store the information outside of the image. Unless you use a bunch of layers.

  9. #389

    Default

    Correct. I know Azure is using Python for his script and coincidentally Python would also be the language I would use. I think full-automation of the process might be too complex with Photoshop, or at least I don't know enough of the ins and outs of it to say.

  10. #390
    Guild Grand Master Azélor's Avatar
    Join Date
    Jul 2008
    Location
    Québec
    Posts
    3,363

    Default

    I think Photoshop can handle python (apparently) but it's not a native language.

    http://techarttiki.blogspot.ca/2008/...th-python.html

    One thing I was wondering is how do you take the wind direction input and convert it to a vector. Well I guess I should start by asking what the input is in the first place. I assume it is something fancier than the arrows made by hand https://www.cartographersguild.com/a...4&d=1442594602

    Maybe the winds are generated using the air pressure maps? After all, most of the time, winds are influenced by pressure differential between two zones and the Coriolis force, and the general atmospheric circulation pattern and mountains. I'm not sure how hard it would be to incorporate all these variables.

Page 39 of 61 FirstFirst ... 2935363738394041424349 ... LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •