LB terrain generator

Hi All,

During these days I have written a new component called LB terrain generator.
I have studied a bit GEO components of gHowl and Google's API.
And I read that there are some limitations when you use Google's API, especially if you'd like to achieve a great quantity of data without overloading Google's servers.

I used a way to request data without overloading Google's servers by using a tiling method. Obviously, this component respects the limit of 2500 requests per day.

This is how the component works:

1) set one point and its coordinates

2) generate surfaces by using isotrim component (Basically, each sub-surface is a request)

3) set the number of division of each surface and the resolution of Google static maps

4) run, move points and generate surfaces with surface from points

5) apply textures to the surfaces

In the image below another small example:

I was thinking that this should be useful for wind simulation with Butterfly, maybe.

Best

Antonello

Replies are closed for this discussion.

Replies to This Discussion

Permalink Reply by Antonello Di Nunzio on October 1, 2016 at 9:08am

Hi djordje,

Now it works fine also without changing the type of input.

Best

Antonello

Permalink Reply by djordje on October 1, 2016 at 9:18am

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?

Permalink Reply by Antonello Di Nunzio on October 1, 2016 at 9:48am

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?

Attachments:

LB_terrainAnalysis test.gh, 1.1 MB

Permalink Reply by djordje on October 1, 2016 at 10:36am

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.

Permalink Reply by Antonello Di Nunzio on October 2, 2016 at 4:33pm

Hi djordje,

I have solved the issue of the origin point, and I have also changed some input names.

Best
Antonello

Permalink Reply by djordje on October 2, 2016 at 5:25pm

The new "originPt" output you have just added, lies on the terrain mesh/surface?

Permalink Reply by Antonello Di Nunzio on October 3, 2016 at 1:55am

Hi djordje,

Yes, the component projects the point onto terrain mesh/surface.

Best

Antonello

Permalink Reply by djordje on October 3, 2016 at 2:17am

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?

Permalink Reply by Antonello Di Nunzio on October 4, 2016 at 4:35pm

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

Permalink Reply by djordje on October 4, 2016 at 4:47pm

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.

Permalink Reply by Antonello Di Nunzio on October 4, 2016 at 5:05pm

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

Permalink Reply by djordje on October 4, 2016 at 5:20pm

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.