Tinfour Project Roadmap
Currently, Tinfour is a one-man project. The long-term plan is to accept contributions from other developers. Migration to a multi-contributor approach will be dependent on code maturity and public interest (i.e. whether anyone actually wants to work on it).
Future work will, of course, depend on whether the Tinfour project develops a user community. The items below describes some ideas we are considering for future development. Your feedback is welcome. And, naturally, if you are interested in undertaking any software development related to the Tinfour project, your participation is welcome.
Adding contouring classes
The current focus for Release 2.1.2 involves adding contouring classes to the API. If you would like to find out more about our progress so far, please see Tinfour Issue 46. We are actively seeking help on some aspects of this implementation effort.
Adding and removing vertices to and from a constrained triangulation
The current implementation does not allow an application to modify the TIN after constraints are added. The motivation for this design choice was mainly performance. If an incremental TIN is permitted to add vertices after constraints are added, then each edge in the neighborhood of the insertion vertex must be tested to see if it is constrained. So the overhead required to permit vertices to be added and removed after constraints are inserted would slow down the construction of the TIN in the phase of operations before constraints are added. But because that function is useful, our hope is that a careful implementation should be able to keep that overhead to a minimum.
The ability to add and remove vertices to a constrained triangulation will permit the implementation of cross-validation tests to evaluate how constraints affect the accuracy of surface modeling. It should also permit the implementation of Delaunay Refinement for Constrained Delaunay Triangulations.
Delaunay triangulations attempt to produce a robust set of triangles, but can sometimes give rise to "skinny" triangles, especially near mesh boundaries and constrained edges. Delaunay refinement techniques attempt to improve the quality of the mesh by inserting artificial vertices (Steiner points) into the TIN. A good discussion of the issues is given by Jonathan Shewchuk's notes on Delaunay refinement.
There's no reason why Delaunay Refinement could not be implemented by an independent developer. In support of that, some of the internal elements in the incremental TIN classes will have to exposed via a public API. The Tinfour development team is prepared to work with any interested party in doing so.
Unifying the standard and semi-virtual incremental TIN classes
In the current implementation, the standard and semi-virtual incremental TIN classes feature a substantial amount of redundant code. This unfortunate state of affairs arose during implementation because of performance issues and the incompatibility of the QuadEdge and SemiVirtualEdge classes used by the respective packages. When I attempted to write code that would use a generic interface for edges, it suffered from substantial performance issues due to the cost of "downcasting" Java references when linking edges together in the TIN. I am currently investigating ways to avoid this overhead and consolidate as much as possible for the two packages.
If you are interested in seeing new capabilities added to Tinfour, I have a couple of ideas and would like to hear about yours. Some of my favorite features in the Tinfour libraries were the result of suggestions made by users.
I'd like to be able to set up a gallery web page that showed images from application that used the Tinfour libraries for practical purposes.
I'd like to see Tinfour do more with Voronoi Diagrams, a graphical structure which is closely related to the Delaunay Triangulation.
I'd also like to have the Tinfour Viewer application extend the support for metadata obtained from LAS files, particularly those elements using Well-Known Text (WKT) format and GeoTIFF tags.