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:
- set one point and its coordinates
- generate surfaces by using isotrim component (Basically, each sub-surface is a request)
- set the number of division of each surface and the resolution of Google static maps
- run, move points and generate surfaces with surface from points
- 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.
Haven’t tried it yet but this looks amazing! You are right that in certain occasions, especially where the height differences are great (e.g. more than 20 meters or even less sometimes) in the landscape then they should be included in CFD studies.
So far I have been using sketch up to do very much the same thing and then import it to Rhino, which probably uses a similar method. Unfortunately, between downloading and importing to Rhino the final maps often have issues with scale and quality of terrain. This can hopefully resolve all that and the need for using two different software.
Once again, thanks for sharing!
Hi all, It will be quite helpful. I don’t know how it will be comparable to Djordje’s development. Nevertheless we should add an input to be able to replace the ground of the wind tunnel with an optional geometry like the terrain surface.
Yes there can definitely add an input for a landscape.
We should take care though with SHM since this mesh is kind of awkward to create with the way SHM works. The reason is the ups and downs of the landscape, it means that on the edges (sides, inlet, outlet) there are parts of the bounding box that will be ‘outside’ of the final mesh. If we mesh it as an outside case, the final mesh will be invalid because it will have surfaces on all sides (probably) extruding outside the volume.
One way to go around this is to treat the wind tunnel case as an internal case. This would mean splitting the bounding box with the landscape and discarding all the leftover bits from the bottom on all sides. Then the final geometry is treated like a huge ‘room’. So in the final boundary file there should be all the masses added by the user, the landscape added by the user, the new split sides, and the top.
Sometimes, depending on how big the model, the additional volume in the blockMesh that would be required to be built around this ‘room’ in order to mesh it (much like we do in the indoor cases) has quite a cost in terms of memory.
I can add an example of this in the weekend.
Very cool stuff. Looking forward to checking this out soon.
here’s an example file of LB terrain generator. You can find the component at LB WIP sub-category.
example_LB_terrain_generator.gh (371 KB)
Hi Antonello, Thanks for posting the example file. It would be great if you can make a Hydra for this example file so it doesn’t get lost after awhile.
Indeed very useful component Antonello !!
Glad to see you are contributing that quickly !
Terrain shading mask component actually creates the terrain first for the chosen location, then makes a mask from it.
The Terrain generator component has been requested by Giacomo few weeks ago. Up until last weekend I have been really busy with the personal work, and couldn’t find any spare time to actually delete the part of the code which creates the mask, and only output the terrain.
Maybe we can release two terrain generators components, taken into account that sources are different (Google maps and Opentopography)?
btw. Antonello I stole your icon for the component. Hope you do not mind.
terrainGenerator2_Sample.gh (444 KB)
I have tried your component, it is great! Especially if you want to create large areas.
You are right about the difference of the sources, in fact I have compared the results of same locations (Vesuvius and Rome, Campidoglio) and the results are very different.
I’m agree with you, we can release both.
P.S. for the icon, it is all right!
Thank you for the component permission, and approval of the icon usage !
I couldn’t test your component due to usage of secure https connection, which does not work on my operating system.
I am not knowledgeable about google maps nor google maps api, but from what I read the two components will definitely show a bit different results due to different topography sources.
If it is judging by this 2010 article, your Terrain Generator component offers much higher precisions for USA. Precision goes up to a couple of meters, which is amazing!!
On the global scale it offers either SRTM 1 or 3 arc-second data or 30 arc-second GLOBE data. Again this is from the mentioned article, I couldn’t find this information by searching the Google Maps website.
Terrain Generator 2 component always uses SRTM 1 arc-second data from opentopography.org, and it is limited to 60 degrees north and does not have data for Antarctica. It does not come with satellite image either which is another very convenient feature that you have!
I couldn’t find information about the allowed radius provided by the Google maps api free account. I limited the “radius_” input to 100 000 meters, even though opentopography.org provides more than that (I successfully downloaded 300 000, but Rhino 5 was not able to create a topography on my PC from such a large amount of data).
Even though I couldn’t compare the results from two components, by looking at your upper example_LB_terrain_generator.gh definition: set the “I” input of “Surface from points” component to True. In this way the surface will be interpolated through points, which is what we want.
Again thank you for the permission, and I look forward seeing those high precision topography that Google maps offers!!
Great work gentlemen!
I just merged in your component, Djordje and I agree that the two different specialties of the APIs make it a good idea to support both components. I just wanted to add that, if anyone wants to nerd-out all of the way and take a look at the raw data that supports both components you can find it all here:
Of course, this data is really unwieldy and the APIs that you guys are both using make A LOT more sense if you want to actually apply the data usefully.
Both components are going to make things a lot easier for a number of people. My mind is already spinning with the possibilities of hydrology studies that we can run off of this easily-accessible topo data.
Keep the great stuff coming!
Thank you Chris, and thank you for the merge.
On providing the usgs.gov SRTM v2 and v2.1 raw data, just a small addition if I may:
Terrain Generator 2 is using SRTM v3 raster data.
A bit more flat and mountainous terrains in v2 and v2.1 had voids in its data set. SRTM v3 finally fixes these voids.
Nevertheless the usgs.gov is quite useful, and provides the data along with documentation.
Hi djordje and Chris,
firstly, thanks for the links and information.
Djordje, I have modified Terrain Generator, I used an input like yours - radius - in this way should be easy to make a terrain model. However I just use rectangular surfaces.
I have followed your advice about the surfaces, and after a couple of tests I saw that meshes should be better, especially when you have big differences of elevation within small zones.
LB terrain generator is not fast but is accurate enough. I’ll send a pull request for this new version soon.
I like the new radius input !
Indeed meshes are the best representation of the terrain, that’s why I used both meshes and surfaces as outputs.
When surface is interpolated through a grid of points it may slightly deform (buldge) due to nurbs tendency to create a smooth surface. Mesh terrain on the other hand will be always be a bit more precise representation of the raster from which it has been created, as it will be consisted of a series of independent faces made from the grid of points.
Btw, you do not have to use the “Delaunay mesh” component.
You can create a rectangular mesh by calling the Ladybug meshFromPoints method:
import scriptcontext as sc
lb_meshpreparation = sc.sticky"ladybug_Mesh"
terrainMesh = lb_meshpreparation.meshFromPoints(numberOfPtsIn_vDirection, numberOfPtsIn_uDirection, pts)
Thanks. I have added terrain Mesh output to LB terrain generator, you can find an example file on Hydra.
If you want and if you are interested you could do a couple of tests to compare the two components. I suggest you don’t go over 2000 meters of radius, you shouldn’t have crash problem but it could require lots of time (minutes).
Keep up the good work!
Hi djordje and Chris,
I have changed the component, I have added the possibility to connect locations directly. This can help you understand where the EPW locations are.
Furthermore, I have written a new small component, Ladybug_Location Finder. This component let you generate locations by typing the address of the location.
Nice. I like the new icon as well!
Amazing stuff, Antonello!
This is going to make us so much less dependent upon the EPW for solar position data.
Feel free to send a pull request whenever you think its good to go!