I’ve been developing a series of Rhino × GIS workflows that integrate geospatial data into Rhino for design and spatial analysis.
This example demonstrates how common GIS terrain analyses can be integrated into a Rhino workflow using geospatial elevation data.
Using a DEM of Mt. Fuji imported with Heron, the workflow includes:
Contours
Slope
Aspect
Hypsometric tint (elevation colouring)
This is one example of how Rhino × GIS workflows can support terrain analysis and geospatial design within Rhino.
I’d be interested to hear how others approach terrain analysis or similar GIS-based workflows in Rhino.
It can automatically generate terrain geometry for a given latitude/longitude and radius - with Terrain Generator component.
Then with Terrain Analysis component, it can perform one of the following 13 analysis:
Slope
Grade
Aspect
Elevation
Visibility
Hillshade
TRI (Terrain Ruggedness Index by Riley)
TRI categories (Terrain Ruggedness Index categories by Riley)
SRF (Surface Roughness Factor by Hobson)
TPI (Topographic Position Index)
Mean curvature
With Legend Bake Parameters component, you can filter the results of the analysis (for example show only terrain where slope is larger than 30 degrees. Or show only terrain which is oriented towards north…).
Example results for Mount Vesuvius:
Here is an example file, in case you want to try it:
Hi @djordje ,
Thanks a lot for taking the time to read the Japanese articles using Google Translate — I really appreciate it!
I knew about Gismo, but I haven’t explored its Terrain Analysis components in much detail yet. The range of analyses you mentioned, especially TRI, TPI, curvature and the filtering options through Legend Bake Parameters, looks really useful.
I come from a GIS background, so I find tools like Gismo and Heron especially valuable because they bring GIS concepts directly into Rhino’s design and modelling environment.
I’d be interested in comparing Gismo with the Heron-based workflow I’ve been using, particularly in terms of terrain acquisition, geographic reference and how the analysis results are handled in Rhino and Grasshopper. Thanks as well for sharing the example file — I’ll take a look.
One thing I’m also curious about: What elevation dataset does Gismo use through OpenTopography for the Terrain Generator component? Is it based on SRTM, another DEM source, or something else?
Kensuke Nakata
USGS10m: only terrain. Only for USA, all Hawaii islands, Puerto Rico, US and British Virgin islands, American Samoa, Alaska. Terrain resolution is 10 meters. Based on USGS.
NASADEM: only terrain from -55.9 to 59.9 latitude. Terrain ends at the sea level (no sea/river/lake floor terrain). Terrain resolution varies from 20 to 30 meters. Based mainly on modified SRTM, but also ASTER GDEM, NED.
AW3D30: only terrain. Terrain ends at the sea level (no sea/river/lake floor terrain). Terrain resolution varies from 20 to 30 meters. Based on Japanese ALOS dataset.
COP30: only terrain. Terrain ends at the sea level (no sea/river/lake floor terrain). Terrain resolution varies from 20 to 30 meters. Based on European WorldDEM dataset.
GMRT: terrain and underwater (sea/ocean floor) terrain. Sea level is not presented. Terrain and underwater terrain resolution varies from 50 meter to 2000 meters.
Values 0 to 5, correspond to input value for “source_”:
Hi, thanks again for the detailed explanation.
I’ve now installed Gismo and tested the Terrain Generator myself. I tried generating terrain around Mt. Fuji using AW3D30, and I found the workflow very intuitive — selecting the location, radius and elevation source made it straightforward to generate the terrain directly in Grasshopper.
As I’m starting to look more closely at how the generated terrain relates back to its geographic source, I wanted to clarify a few points.
From the component behaviour and source code, it looks like Gismo uses the input latitude/longitude as the geographic reference for the generated terrain and reprojects the downloaded elevation raster to the corresponding UTM zone before creating the Rhino geometry.
What I’m particularly interested in is how that geographic relationship is represented after the terrain has been generated:
Are the X/Y distances in the resulting Rhino geometry represented in metres?
Is the UTM / CRS information retained anywhere in the Rhino document or object metadata, or is it only used internally during terrain generation?
Is any geographic reference information stored with the resulting Rhino geometry, or would the relationship to the original latitude/longitude need to be reconstructed from the original input settings?
I’d like to understand this correctly before working further with the terrain data in Rhino.
If you could clarify these points, it would also make it much easier for me to introduce Gismo accurately to Rhino users in Japan.
Thanks again for sharing the example and for taking the time to explain how Gismo works!
Kensuke Nakata
Yes, you are correct - Gismo calculates the UTM zone for northern or southern hemisphere, based on input location’s latitude+longitude.
Gismo’s Terrain Generator, and all other components - always has inputs in meters.
However, the final terrain geometry can be in any units, as Gismo’s components will adapt to the currently chosen ones from Rhino. So if a user chose “feet” as units in Rhino, then Terrain Generator will create a terrain geometry in feet units.
Yes, at the moment this information is only used internally.
But if you could show me an example, maybe we could expose this information.
Gismo’s Earth Anchor Point component can be used for this.
It will essentially record your location’s latitude and longitude, to Rhino’s 0,0,0 coordinate. And this information will remain like that, once you save a .3dm file.
You can check this information via Rhino’s EarthAnchorPoint command.
I attached one example.
Thanks again for the detailed explanation. It’s clear now, and I’ve continued testing the terrain workflow around Mt. Fuji using AW3D30.
For the Mt. Fuji location I’m testing (35.3606, 138.7274), could you tell me the exact UTM CRS / EPSG code that Terrain Generator uses internally? I’d like to understand the spatial reference precisely before continuing the test.
Also, with radius_ = 5000 m, the generated terrain measures approximately 4502m from the origin to the edge in Rhino. Looking at the source code, I noticed that the cutting radius appears to use radius_ * 0.9. Is it correct that the final terrain is intentionally cropped to approximately 90% of the specified radius?
I’ve attached a screenshot showing the measurement.
Reduced radius.
Indeed this is True. From time to time, once the terrain raster got projected, some strange results have been appearing at the outer edges of the terrain geometry.
To prevent these, I simply cut them off, thus the reduced radius you noticed.
If you want to fix it, the replace the line 1220: terrain, title, elevationContours = title_scalingRotating(terrainUnoriginUnscaledUnrotated, locationName, locationLatitudeD, locationLongitudeD, locationPt, maxVisibilityRadiusM, _type, sourceLabel, origin, northDeg, northRad, numOfContours, unitConversionFactor)
Thanks, this was very helpful!
I added print CRS_EPSG_code as you suggested and successfully extracted 32654 for the Mt. Fuji location (35.3606, 138.7274). So I can confirm that Gismo is using WGS 84 / UTM zone 54N (EPSG:32654) internally for this location.
The reduced radius also makes sense now. With radius_ = 5000 m, I measured approximately 4502 m from the origin to the terrain edge, which is consistent with the 0.9 trimming you described. Thanks also for showing how to make the radius shown in the title output match the actual terrain extent.
As for the terrain type, I confirmed that type_ = 0 or 1 generates the mesh terrain correctly, but Terrain Analysis reports that its _terrain input requires a surface or polysurface and asks for type_ = 2 or 3. I’ve attached a screenshot showing this behaviour.
So, as I understand it, mesh terrain can be generated with types 0/1, while Terrain Analysis specifically requires the surface output from types 2/3. Is that correct?
I’ve also been exploring how Gismo and Heron could be combined in a terrain workflow, particularly in terms of georeferencing and spatial reference. During that testing, I found an issue when Gismo’s Terrain Generator and Heron’s Set Spatial Reference System (SetSRS) are used in the same Rhino 8 session.
Would it be alright if I start a separate thread about this and invite Brian Washburn to join the discussion, so that we can look at the issue from both the Gismo and Heron sides?
Yes, this is correct.
Also if you want to analyse water flow on terrain with Gismo’s Flow Paths component, I as well recommend using the type_ input set to 2/3.
I mentioned Legend Bake Parameters component earlier.
Attached is one example, how you can use this component to filter the results. In this case the results of Aspect Terrain Analysis.
Attached definition shows only southern terrain slopes of Mount Vesuvius (red colored).
We do this by filtering only 157.5 to 202.5 degrees aspect angles:
Another useful feature can be Gismo’s Color Palette component.
It has some predefined colors, which you can use to color results of Terrain Analysis component:
