Closed TheLaughableCoder closed 7 years ago
To clarify, the code at the moment takes in one DEM and one terrain classified dataset to produce the wind multipliers. Do you mean that having multiple output files is taking up too much disk space? The outputs from this code are a terrain, topography and shielding file for each tile, for each wind direction.
Yes, if you only want to get the wind loading at one location it would be great to have the option to do this on the fly. I'm no expert but I believe the topography and to some extents the sheilding is derived from the DEM.
You're correct - the topography and shielding multipliers are both derived from the input DEM.
This code base is set up as part of a larger work flow that feeds into Geoscience Australia's Tropical Cyclone Risk Model (https://github.com/GeoscienceAustralia/tcrm/tree/v3.0_beta). The multipliers calculated in this code repo are inputs to the "Process Multipliers" code within TCRM.
It sounds like you're after a different use case for this code. Can you outline specifically what you would like this code to do, and we can see if we can accommodate that. What outputs are you specifically looking for? It sounds like you're after a more point-based calculation, rather than the spatial tile-based calculations this code is designed to do?
Correct. Just point based calculation.
On Tue., 23 May 2017, 7:22 am Claire, notifications@github.com wrote:
You're correct - the topography and shielding multipliers are both derived from the input DEM.
This code base is set up as part of a larger work flow that feeds into Geoscience Australia's Tropical Cyclone Risk Model ( https://github.com/GeoscienceAustralia/tcrm/tree/v3.0_beta). The multipliers calculated in this code repo are inputs to the "Process Multipliers" code within TCRM.
It sounds like you're after a different use case for this code. Can you outline specifically what you would like this code to do, and we can see if we can accommodate that. What outputs are you specifically looking for? It sounds like you're after a more point-based calculation, rather than the spatial tile-based calculations this code is designed to do?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/GeoscienceAustralia/Wind_multipliers/issues/9#issuecomment-303246389, or mute the thread https://github.com/notifications/unsubscribe-auth/AIUf7KBpjPiMy4R1PJ17tlilvE_4-6V6ks5r8hipgaJpZM4Nh-eE .
P Please consider the environment before printing this email
The extent of the output multipliers is based on the extents of the input DEM and terrain datasets. In the short term, you could just use a small spatial extent for these, centred on your point of interest. You will need some spatial context for a point-based assessment anyway.
You may also want to look at the Process Multipliers code (https://github.com/GeoscienceAustralia/tcrm/tree/v3.0_beta/ProcessMultipliers) that we use to combine the multiple multipliers produced here into a combined terrain, topography, shielding and direction multiplier. This code is still in development, but might be what you are after in terms of having smaller output?
Thanks. I will look into it
On Tue., 23 May 2017, 7:29 am Claire, notifications@github.com wrote:
The extent of the output multipliers is based on the extents of the input DEM and terrain datasets. In the short term, you could just use a small spatial extent for these, centred on your point of interest. You will need some spatial context for a point-based assessment anyway.
You may also want to look at the Process Multipliers code ( https://github.com/GeoscienceAustralia/tcrm/tree/v3.0_beta/ProcessMultipliers) that we use to combine the multiple multipliers produced here into a combined terrain, topography, shielding and direction multiplier. This code is still in development, but might be what you are after in terms of having smaller output?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/GeoscienceAustralia/Wind_multipliers/issues/9#issuecomment-303247586, or mute the thread https://github.com/notifications/unsubscribe-auth/AIUf7Muje7YIIsNPPNezQSJ79J2an60lks5r8hpkgaJpZM4Nh-eE .
P Please consider the environment before printing this email
The code is designed to work across large spatial extents to enable mapping of the multiplier factors. It's not intended for use in determining point values, and we don't currently plan to enable that kind of calculation. Some of the algorithms could be used for calculating the point values, but you would have to write customised code to extract the required input values (DEM, terrain cover, shielding factors) in an appropriate manner to pass into the core algorithm.
One way we have done point data in the past is to run the calculation over a spatial domain, then extract the multiplier factors point by point to allow calculations on point data.
Is it possible just to use the one DEM dataset, and then have that automatically generate the topographic and shielding information on the fly rather than having a data set for each cardinal wind directions?
This could save on disk space.