Data sets too large

[TheLaughableCoder]

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.

[CEKrause]

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.

[TheLaughableCoder]

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.

[CEKrause]

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?

[TheLaughableCoder]

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 .

-- The information contained in any e-mail and its attached files, including replies and forwarded copies, is confidential and intended solely for the addressee(s) and may be legally privileged or prohibited from disclosure and unauthorised use.• If you are not the named addressee you may not use, copy or disclose this information to any other person. • If you received this message in error please notify the sender immediately and delete all copies of the email and associated files. • If you are not the intended recipient, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication or any action taken or omitted to be taken in reliance upon this message or its attachments is prohibited and may be unlawful. • Any views or opinions presented are solely those of the originator and do not necessarily represent those of the company. • All liability for viruses is excluded to the fullest extent permitted by law. • Although every effort has been made to ensure the correctness and integrity of attachments that may be included in this email, this can only apply to the unaltered/uncorrupted form. A copy of the original attachment is available from our office should you require it. • Alternatively, if further verification is required please request a hard copy version.

P Please consider the environment before printing this email

[CEKrause]

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?

[TheLaughableCoder]

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 .

-- The information contained in any e-mail and its attached files, including replies and forwarded copies, is confidential and intended solely for the addressee(s) and may be legally privileged or prohibited from disclosure and unauthorised use.• If you are not the named addressee you may not use, copy or disclose this information to any other person. • If you received this message in error please notify the sender immediately and delete all copies of the email and associated files. • If you are not the intended recipient, any form of reproduction, dissemination, copying, disclosure, modification, distribution and/or publication or any action taken or omitted to be taken in reliance upon this message or its attachments is prohibited and may be unlawful. • Any views or opinions presented are solely those of the originator and do not necessarily represent those of the company. • All liability for viruses is excluded to the fullest extent permitted by law. • Although every effort has been made to ensure the correctness and integrity of attachments that may be included in this email, this can only apply to the unaltered/uncorrupted form. A copy of the original attachment is available from our office should you require it. • Alternatively, if further verification is required please request a hard copy version.

P Please consider the environment before printing this email

[wcarthur]

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.