Thursday, 7 April 2011

Slope/Aspect/Elevation using JTS

David Skea is a longtime colleague, JTS contributor, and all-around geospatial guru. He's developing a Slope/Aspect/Elevation service to be used in forestry-related applications here in British Columbia. His work is a nice example of using JTS to perform real-world spatial processing.

The key to computing slope, aspect and elevation is to have a Digital Elevation Model (DEM) available for the terrain in the area of interest. In this case, the terrain data is provided by the TRIM irregular DEM, which is a dataset of over 500 million mass points covering all of British Columbia. To compute the required values for a given polygon, the first step is to extract only the mass points in the immediate region of the polygon (i.e. using the polygon envelope with a suitable buffer distance. The JTS Delaunay Triangulation API is used to compute a TIN triangulation from the TRIM mass points.

Using a JTS PointOnGeometryLocator, the triangles whose centroids lie in the polygon are selected. Since each mass point has an elevation value, each TIN triangle is located in 3D space. The normal vector can be computed for each triangle, which provides the slope and aspect values. The elevation is the height of the triangle centroid.

The SEA values for the triangles are averaged to compute the overall slope, aspect and elevation value for the polygon.

Here's a screenshot showing the results, using Google Earth as a convenient 3D visualization tool (click for full-size image).


Unknown said...


I didn't realize JTS had any functions that supported Z of any sort. Is this a new development or have I just been living in a cave for too long?

Does this mean JTS Delaunay Triangulation API supports 3D TIN creation? Hmm I see - Evil genius at work

Dr JTS said...

Well, JTS has always supported a Z-value on coordinates. This provides so-called 2.5D, which isn't true 3D but is quite useful in the geospatial world.

But you're right, there hasn't been much functionality that uses Z directly.

It turned out to be easy to support Z values in the triangulation code, and 3D TINs are a MAJOR use case, so it totally made sense to make sure this works.

I'll probably add some more 3D functions as time goes on - the 3D normal vector used in the SEA service is a good example