Module 1 Documentation

tin Package

TriangulatedIrregularNetwork extends MultiPolygon (I'm debating whether or not to directly inherit from MultiPolygon or to add more interfaces to create a MultiPolygon->Surface->PolygonalSurface->TIN hierarchy that is closer to the Simple Features spec)

In order for the TIN code to integrate seamlessly with OpenJUMP, the interface to the in-memory representation of the TIN should be as compatible as possible with the JTS. By making the TIN a MultiPolygon with the added restrictions that all Polygons are non-overlapping, connected triangles, all the code that works with GeometryCollections can be made to easily work with TINs. Internally, the TIN surface will be represented by a triangle-table which is a simplified version of a quad-edge data structure. Each record in the table represents a triangle and contains the three vertex points and three table keys that point to the bordering triangles within the triangle table. The vertexes will be stored as raw doubles and the lines inferred. When the class is queried for a triangle or point, the returned geometry object will be created on the fly from the internal data structure. If this proves too slow, then it might be worth the space tradeoff to store the vertexes as Point Objects. This data structure is compact, fast and can accomplish anything we would want to do with a TIN.

In addition to the inherited GeometryCollection methods and the methods specified in the Simple Features spec for Surfaces and PolyhedralSurfaces, the TIN class should also have TIN specific methods like:

• extractContourBands: given a height increment and baseline (default = 0), return a MultiLineString containing the contour bands separated by the given height increment.
• subset: given an envelope or even a linear ring, return a TIN that contains all the triangles of the current TIN that lie within the given boundary.

I'm still not 100% clear on OpenJUMP's rendering pipeline, but it looks like I will implement a new instance of com.vividsolutions.jump.workbench.ui.renderer.Renderer that will work with TINs such that elevation color bands and hillshades can be implemented by coloring/shading each triangle on the fly. If this winds up being too slow, I might have to add pre-computed normals to the TIN's triangle-table.

TinFactory

For efficiency sake, the TIN should be immutable, thus a Factory will be needed to create a TIN fully formed. This Factory would be analogous to the GeometryFactory class. Various methods would take input lines and points and output a fully constructed instance of a TriangulatedIrregularNetwork. The first factory I'll work on will take a MultiPoint set and use Chew's algorithm found in org.openjump.core.graph.delauneySimplexInsert. This algorithm isn't the fastest, and doesn't deal with breaklines, but it is already in the OpenJUMP code base and will help to get the TIN pipeline working faster. The next factory to be coded will take a MultiPoint collection and a MultiLineString collection and will use a constrained delaunay triangulation to create the TIN. We may want to do a conforming delaunay triangulation instead and add steiner points on the breaklines in order to not have huge triangles next to the breaklines. Steiner points are also the reason why the TIN class should contain the copy of it's breaklines, because the breaklines in the TIN might be different than the breaklines that were initially given to the factory (the TIN's breaklines would have more points). Later on down the road, I would also like to make a TinFactory that takes in a MultiLineString of breaklines and a stream of Points, then builds up the TIN until the stream closes. This will be useful when we move beyond OpenJUMP's in memory representation and embrace larger TINs.

tin.io Package

This package will contain classes that can turn various types of input files into MultiPoint / point streams and MultiLineString geometry to be input into a TinFactory. There will also be classes that can export a TIN to a file and then be read it back into a TIN class. At first only Well Known Text input and output will be implemented. Eventually various DEM files will be supported for input and various 3D formats supported for input and output (i.e. W3's X3D).

tin.viewshed Package

All the papers I've read about viewsheds use a separate data structure for the viewshed that is built from the TIN. This data structure is then queried. The query could be a point or line with the return value being a MultiPolygon containing regions that can be seen from the input feature. The query could also be two features with the return value being a boolean indicating whether or not the features are visible from each other. The downside to viewsheds is that they have a big memory footprint: the most versatile data structure has a table for each point that contains a boolean value for every other point in the TIN indicating if it is visible or not. Because of this, viewsheds shouldn't be integrated into the TIN class and should only be used when requested.

tin.watershed Package

Much like the viewshed package, separate data structures that are built using the TIN will be needed.

tin.multitriangulation Package

The classes in this package will implement a multi-resolution triangulation model. The MT data structure can return a TIN class with a specified level of detail. The LOD can be constant over the whole surface, or can be higher at specified locations and coarser at others. This won't be of much use if the TIN can fit in memory, but once the TIN gets bigger, a multi-resolution data structure can use a file or database backing and return a TIN in a resolution that will fit in memory and cover the points of interest at the required detail. This might wind up being implemented solely within PostGIS/WMS, so that OpenJUMP can simply issue a WMS query and receive a TIN object as a reply.