This is very nice! Is it already added to Ladybug?
Mostapha,
Yes, I merged everything in the other day. It’s all in the WIP section at the moment.
Hi Mostapha, Chris and djordje,
Please, let me know if LB Location Finder works fine. It requires a secure connection because of one of the Google’s API.
This is a small test where I used chinese and korean characters.
Best
Antonello
Hi Antonello,
My apology for taking me too long to reply.
I couldn’t test your component on my PC due to it not supporting the System.Net.WebClient class.
I tested your component on my friend’s PC tonight, and it worked great!
I can already see some of the nice benefits of its usage. With the Google Earth component, you made a quite a remarkable addition to the Ladybug set of components! Keep up this great work!
Just as a mention: I am attaching a screenshot of two new components:
The first one: “Terrain analysis” performs a couple of terrain analysis types, and the second one: “Flow paths” performing the water flow analysis.
Screenshot example of both is given below:
It would be nice if your Terrain Generator component could benefit from using these two new ones.
In order to do that, Terrain Generator would have to output the terrain in a form of surface as well. My modest advice would be to add the “type_” input, which will determine whether the “terrain” output is a mesh, or a surface. This will make it consistent with Terrain Generator 2 component.
To create the terrain surface from a grid of points, use the NurbsSurface.CreateThroughPoints method:
import Rhino as rc
uDegree = vDegree = 3
uClosed = vClosed = False
terrainSurface = rc.Geometry.NurbsSurface.CreateThroughPoints(pts, numberOfPtsIn_vDirection, numberOfPtsIn_uDirection, uDegree, vDegree, uClosed, vClosed)
Of course this is just a suggestion, I am not imposing anything.
1 Like
Hi djordje,
amazing stuff! Thanks for your advice. I have modified LB Terrain Generator to try your components.
I have changed _geometry and _terrain from “ghdoc object” into “No type hint” in order to use your components because my terrain surfaces weren’t recognized.
As you can see from the images, the analysis results are amazing. Great work!
I’m going to send a pull request today 
in this way you could find how to manage terrain imput of LB Terrain Generator in the checking phase.
Best
Antonello
Hi djordje,
Now it works fine also without changing the type of input.
Best
Antonello
Hi Antonello,
Your Terrain Generator component is also using the System.Net.WebClient class, which does not work on my PC.
So I can not test your component at the moment, but the issue you had was strange.
I have changed _geometry and _terrain from “ghdoc object” into “No type hint” in order to use your components because my terrain surfaces weren’t recognized.
…
Now it works fine also without changing the type of input.
When do “Terrain Analysis” and “Flow paths” components work for you, and when they do not? Can you attach and internalize the specific terrain surface which forced you to change the input hints?
Hi djordje,
it is weird but I can’t reproduce the error now, it works fine.
About the System.Net.WebClient class, do you have any suggestion?
LB_terrainAnalysis test.gh (1.14 MB)
Hi Antonello,
Thank you for the attached file. Both surfaces you internalized work at my place without a problem.
I’ve noticed one inconsistency between the Terrain Generator and Terrain Generator 2 components.
At Terrain Generator 2 component, the “origin_” input and “originPt” output represent a point of the terrain. So the terrain surface or mesh will be created starting from that spot, where that spot is actually lying on the very terrain.
I noticed that this is not the case with “_basePoint” input of Terrain Generator component.
In that case, in order for it to be able to use the Terrain Analysis component, one has to project the “_basePoint” to terrain mesh/surface.
We tried to fix the WebClient class issue with Mostapha and Chris last year, but without success. Eventually I will have to buy a new PC and install a newer operating system, which will remove the issue. Until then I will not be able to test some of other people’s component’s which use this class.
I apologize if this is causing you any inconvenience.
Hi djordje,
I have solved the issue of the origin point, and I have also changed some input names.
Best
Antonello
The new “originPt” output you have just added, lies on the terrain mesh/surface?
Hi djordje,
Yes, the component projects the point onto terrain mesh/surface.
Best
Antonello
Isn’t there a bit of ambiguity between “origin” input and “originPt” output of the “Terrain Generator” component?
They now represent two completely different points?
“origin” input is lying on the “tiles” while “originPt” is lying on the “terrain” surface:
Or am I wrong?
Hi djordje,
“origin” is defined by users and if this input is empty the default value is {0;0;0} whilst " originPt" is the “origin” projected onto surface. This is because the component generates terrain models from points which are placed in the right place by using elevation values.
Probably, I should move the terrain at the same level of the “origin” input.
However I think the outputs are correct for the analysis component.
At the moment the concept is this:
Best
Antonello
Hi Antonello,
Thank you for the reply and the visual explanation.
I think it could be beneficial if you would keep your “_basePoint” (or maybe even “baseOrigin") input instead of “origin”.
In this way there will be no confusion between the input and output points. At the moment, “origin” input and “originPt” output of “Terrain Generator” component represent two completely different points. While "origin” input and “originPt” output of the “Terrain Generator 2” component are the same points.
I think we should also rename the output “originPt” to “origin”. I would do the same with “Terrain Generator 2” component.
Sorry if this looks like a nitpicking. It’s just in my opinion we should at least make both “Terrain Generator” components acting similar, at least when it comes to them being the predecessor components for other ones (like “Terrain Analysis”).
I would like to hear your thoughts.
djordje,
You are right and your idea sounds good. “basePoint” as input and “origin” as output.
I should see what happens if I add the code lines that put the terrain at the origin like LB terrain generator 2.
Best
Antonello
Thank you Antonello.
I was not complaining that the “basePoint” needs to be on the terrain. I perfectly understand the concept of raising the points from the base (where the tiles are) upwards.
I just suggested that a point input name (regardless if it lies on a terrain surface/mesh or not) should probably not have a very similar name to the output which lies on the terrain surface/mesh.
So I am ok with “Terrain Generator” component keeping the “basePoint” input to lie on the same plane where the “tiles” are.
Ok, I will change the name output of the “Terrain Generator 2” component from “originPt” to “origin” and I will edit the hover text of each of “Terrain Analysis” component’s required inputs, that they can use both “Terrain Generator” and “Terrain Generator 2” data.
Thank you once again for the permission, and sorry for being a bit too picky on this.
Ok! thanks a lot, djordje!
Is it correct to use a workflow for the visibility analysis like this?
Hi Antonello,
Not really. Initially I’ve planned to use only the _origin point and its elevation (the central point from the “Terrain Generator 2” component) for visibility analysis. So basically the visibility would always be calculated starting from that point (that’s the photo on the left, below).
But you have just discovered a new way of choosing a custom point! Thank you for that! (that’s the photo on the right):
By the way, the Visibility legend coloring scheme in “Terrain analysis” component had a bug, which is visible on the last photo you attached. I waited for us to settle the origins input/output name before fixing it. The newest version of Terrain analysis has it fixed. I also added text to _terrain, _origin, and _elevation docstrings suggesting the usage of “Terrain Generator” component data as well.
Also, try setting the “refine” input to “True”. It will increase the quality of the final analysedTerrain mesh.
Once again, thank you Antonello for the useful support and collaboration!
Hi djordje,
thanks for the updates. Now the analysis component works fine.
I have also found a way to project textures onto terrain models.
