Adding Topography to the Site Model – Example 20.2

September 19, 2014

So you have a nice 2D document started and now you want to add some topography? Well, it is possible with Elk, and the process seems pretty straightforward at first, but unfortunately it is a little glitchy. There are ways to work around the glitches though, to generate a good base terrain for further steps in creating the model.

Getting Data

The first thing you will want to do is get some topographic data. The plugin Elk can accept only one kind of Topographic data, *.hgt files from the Shuttle Radar Topography mission, often abbreviated as SRTM. You can read about the mission, but basically what the US did was to fly the space shuttle around the world for 11 days equipped with a radar scanner. The radar scanner mapped most of the earth (all land between 56°S and 60° N) on a 90m grid and using the data, one can determine the height of any point of land to within a few meters of accuracy, with a maximum inaccuracy of around 9m. There are reports on the NASA website that describe the process in detail.

The good news is after spending all this money, the data was released to the public around the world absolutely free of charge. Having a consistent set of topographic data for most of the planet can further be used for studies of hydrology, geomorphology, climate, and a huge number of other global data sets derive from this data.

You can download the *.hgt files here. There is one *.hgt file for each degree of Latitude and Longitude, labelled according to the Southwest Corner of the dataset. So if the coordinates for your project are 46.35°N and 07.05°E, the file you need will be N46E007.  But be careful! If the project is West of the Prime Meridian, say 57.12°N and 01.05°W, the file you need is actually N57W002. Likewise for the southern hemisphere, if you are 22.5° S you will need a file in the S23 set. Also, if your map crosses a line of latitude or longitude, you will need to make 2 separate models.

Some other people have taken it upon themselves to fill the gaps in the data, making elevation data sets from topographic maps, using interpolation algorithms to fill voids, etc. One particularly industrious hobbyist, Jonathan de Ferranti started the website Viewfinder Panoramas where much of the best topographic data available is assembled, including for areas the SRTM mission didn’t map. Click on the word “global” on the line about Digital Elevation models.

Basic Elk Setup

OK, so we have an *.hgt file. Now we simply set up a script using Elk similar to the image below. The *.hgt file is referenced into Grasshopper with a “File Path” parameter, and plugged into Elk’s sTopo component. You should also plug in the “Lo” and “La” outputs from the Elk “Loc” component into sTopo’s “La” and “Lo” ports. Be careful to put it into the right ones though! the wires are crossed. Once correctly set up, this spits out 3 different data streams, elevation points, Curves, and a Surface.

This seems easy, but there is a huge problem with the current release of Elk. The programmer didn’t account for the fact that 1° of latitude does not have the same dimensions as 1° of longitude, especially as you go further north. On the whole planet, one degree of Latitude is consistently 111 km apart. One degree of Longitude, however, varies from 111 km at the equator to 0km at the poles. In Hannover Germany at 52° N one degree of Longitude equals about 68km. However, regardless of where you are on the planet, Elk will spit out a model where the latitude dimension equals the longitude dimension. In other words, a model that uses the entire *.hgt data set N52E009, the coordinates for Hannover Germany, should be 111 x 68 but it comes out of Elk with the dimensions 111 x 111. A pretty serious problem!

Fixing the Elk Scaling Problem

So hopefully the programmer will read this or some other complaint and fix Elk to account for this, but in the mean time, to fix this yourself, you can use the Scale NU component on the data output from Elk. Don’t scale anything in the y direction, but use a scale factor in the x direction to get the model down to size. You can use a mathematical formula to determine the scale factor you need, but I made a Grasshopper “Cluster” that will spit out the right scale factor for longitude based on your latitude, and will scale the model as well. There are a few simplified formulas for calculating the proper scale factor which assume the earth is a perfect sphere, and these could be fine, but I wanted to be more precise, considering the earth is a slightly squashed ellipse, so I made a geometric model that will calculate the scale factor for you. A bit complicated, but I only had to do this once and now every model will come out at the right scale. I guess technically it should be scaled where the top of the model is slightly smaller than the bottom.. but maybe that’s a bit much 😉

Geometric Model to Determine the Radius of Earth along a given degree of Latitude. This is used to get the Circumference, and divided by 360 to get the measurement of 1° of Longitude.

Cluster for scaling – All the contents of the large red box below are packaged into what looks like one component.

Drawing Contours

So now you should have an acceptable surface. You can now extract contours at an appropriate interval. I decided to make my contours look a little nicer with dashed and heavy lines, but the dash function can eat up a lot of computer resources. If you overlay your output contours and your output from Example 20.1 in 2D it will look like a contour map, but in 3D you will notice the contours are at the proper height above sea level, but everything else is still flat. We will start to fix that in the next exercise.

Overall script for generating contours

 

The grasshopper file for scaling the geometry from Elk and for generating and sorting the contours can be downloaded here…

 

Filling Voids

One other problem you may run into, especially if you are doing a model in a very mountainous area, are data voids. The SRTM worked pretty well, but sometimes the signal was lost due to rugged terrain or other factors. Where no data was obtained from a survey point, they set the height value to -37000 ft. The result is if you input an un-fixed *.hgt file, your elk model will look something like this.

This bottomless pit actually doesn’t exist. At first my solution to this problem was to bake the points, delete the negative points, and use the remaining points to create a patch surface. A better solution might be to use a process in grasshopper to Cull the negative value points, and then to rebuild the curves, and then the surface, from the remaining points. The image below shows one way this could be done.

Inside of “Cluster” to get rid of Invalid Points

Post navigation

← 2D Site Model from Open Street Maps – Example 20.1

Projecting Geometry to Surface – Project Point – Example 20.3 →