Terrain shading mask component released

EDIT: Both Terrain shading mask and Horizon angles components are now part of Gismo plugin. For future suggestions, issues, bugs, post a question in Gismo' plugin group.

Hello,

I would just like to make a modest notice about the two new Ladybug components, one of which creates a 3d terrain shading mask and another one which visualizes and exports horizon angles.

A terrain shading mask is essentially a diagram which maps the silhouette of the surrounding terrain (hills, valleys, mountains, tree tops...) around the chosen location, and account for the shading losses from the terrain.
It can be used as a context_ input in mountainous or higher latitude regions for any kind of sun related analysis: sunlight hours analysis, solar radiation analysis, view analysis, photovoltaics/solar water heating sunpath shading...

My home town is an example of the shading caused by the terrain. Here is how it looks from the tallest building in the town:

And the created terrain shading mask:

A mask for any land location up to 60 degrees North can be created:

There will also be a support for a few major cities above this limit.

Both Terrain shading mask and Horizon angles components can be downloaded from here.
An example .gh file can be found in here.

Component will prompt the user to download and copy certain files in order to be able to run.

It was created with assistance from Dr. Bojan Savric.
Support on various issues was further given by:
Dr. Graham Dawson, Dr. Alec Bennett, Dr. Ulrich Deuschle, Andrew T. Young, LiMinlu, Jonathan de Ferranti, Michal Migurski, Christopher Crosby, Even Rouault, Tamas Szekeres, Izabela Spasic, Mostapha Sadeghipour Roudsari, Dragan Milenkovic, Chen Weiqing, Menno Deij-van Rijswijk and gis.stackexchange.com community.

I hope somebody might find the components useful.

Replies are closed for this discussion.

Replies to This Discussion

Permalink Reply by djordje on August 7, 2016 at 2:39pm

Hi Abraham,

The "Terrain shading mask" mask component will scale the mask inside of it, and output it (scaled) through its terrainShadingMask output. No manual scaling should be performed.
The scaled mask from the terrainShadingMask ouput can then be plugged to any other component's context input.

What sort of specific example do you need?

Permalink Reply by Abraham Yezioro on August 7, 2016 at 10:35pm

Hi Djordje,

Thanks.

After your previous response i get a bit confused regarding the "correct" size of the mask in relation to the model geometry.

Now i want to think out loud and tell me if i'm right or wrong:

Running the terrainMask without context gives you the mask with the original sunPath scale.

This mask is calculated up to about 100km from the location.

There is no need to scale anymore the mask? But here, is one doubt. Say i have a large model or a small one. For the fomer i want the mask to be beyond the limits of the model, so i'll scale it down ...? This won't affect the solar/radiation calculations results (or the other way around: scale up.

This is the kind of example/situation i want to be clear. I suppose and assume other will alsodo.

Thanks,

-A.

Permalink Reply by djordje on August 8, 2016 at 5:33am

Hi Abraham,

Running the terrainMask without context gives you the mask with the original sunPath scale.

Yes, you are correct: if nothing is inputted into the context_ input, the radius of the final terrainShadingMask output will always be 200 meters (or 655 feets in case of Feet unit system). This corresponds to the default radius of the "Sunpath" component (_sunPathScale_ = 1). This geometry is suppose to be used for visualization purposes only.

There is no need to scale anymore the mask?

Yes. No manual scaling should be performed. The "Terrain shading mask" component will perform the scaling based on the size of context_ input's bounding box.

But here, is one doubt. Say i have a large model or a small one. For the fomer i want the mask to be beyond the limits of the model, so i'll scale it down ...? This won't affect the solar/radiation calculations results (or the other way around: scale up.

The mask will always be scaled in a way so that it goes beyond the limits of the context_ input. It will never intersect with the context_ input. Unless your context input is consisted of a building blocks, a couple of hundreds of meters in diameter, somewhere high in the mountains: you will probably end up with 10 000 meters mask radius.

I didn't understand you about the affect of the solar radiation results.
You mean: does scaling of the mask affects the solar radiation results?

Please let me know without hesitation if I missed to answer some of your questions.

Permalink Reply by Abraham Yezioro on August 8, 2016 at 9:08am

Ok Djordje ... just because you asked for that ... :-)

The process of getting the mask is understood. The process of using it as a context for daylight/radiation/etc analysis is less.

So let's assume two cases for the same location:

1. Small scale. Only one room, where i want to get a daylight analysis.

2. Big scale. Urban area (say 10 by 10 blocks, for the sake of the discussion), where i want to perform a radiation analysis on the blocks.

So, different scales, and different tasks. The question is, what would be the flowchart to do the job taking correctly the influence of the mask for both.

I believe i'm missing something from your explanation, but hopefully your answer will help not only me, but others to have a good and correct use of the component.

Makes sense what i'm asking?

Thanks,

-A.

Permalink Reply by djordje on August 8, 2016 at 2:02pm

1) You would have to connect all the geometry you have (a room, and the ground surface around the room to the context_ input). The "Terrain shading mask" component would then scale the mask, and depending on the topography of your location you will probably end up with a 10 000 meters mask radius.

2) Again you would plug in all the geometry (those blocks) into the context_ input. Depending on the topography of the location, you will probably end up with a mask radius higher than 10 000 meters.
But in this case the default value of 0 of the minVisibilityRadius_ input needs to be increased, so that the topography near the location gets excluded. Which is exactly what the minVisibilityRadius_ serves for.
To my knowledge there is no paper which describes the exact amount of the minVisibilityRadius_ which needs to be used.
ShadeUp plugin for example uses 50 meters of minVisibilityRadius_ by default and 50 000 meters of maxVisibilityRadius_ by default, for objects of a tens of meters in diameter.
Something similar can be applied to our minVisibilityRadius_ input. For example: for relatively flat location surroundings one can use minVisibilityRadius_ to be at least 3 times larger than the contextRadius output. For more hilly locations surroundings this value can be increased (6, 7 times of the contextRadius).
For example if the contextRadius is 600 meters, minVisibilityRadius_ can be 3.6 kilometers, and so on.

Let me know if this answers your questions.