Reply With Quote
I think the driest lapse rate is close to 10°C/km.Originally Posted by Charerg
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.
I think the driest lapse rate is close to 10°C/km.
My Deviantart: https://vincent--l.deviantart.com/
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
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.
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
What is a A pixel-by-pixel vector map ? each direction would have a different colour?
That is doable, but the maximum value would be 255. With 2 degrees per pixel instead of one, it's still precise enough.a pixel object that holds various values for wind direction, wind strength, amount of moisture carried, etc., to generate the (rough) precipitation map.
My Deviantart: https://vincent--l.deviantart.com/
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.
Last edited by antillies; 03-15-2018 at 06:57 PM. Reason: Added some images for clarification.
So you would need to store the information outside of the image. Unless you use a bunch of layers.
My Deviantart: https://vincent--l.deviantart.com/
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.
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.
My Deviantart: https://vincent--l.deviantart.com/
