I currently have the JTIN library designed so that all
the heavy lifting data structures are are located at
the Geometry level while all the display code is at
the Layer level.
For instance:
* TinFace extends Geometry: contains a Triangle object
and links to neighboring faces.
* TIN extends GeometryCollection: contains an array of
TinFaces and all the methods that will be used to
extract information from the TIN (like elevation
bands, or visibility matrices).
Then the TIN will be the only Geometry in a feature
and that feature will be the only one in the Layer.
The Layer will be customized so that conversion to
Java2D can happen without the overhead of generating a
massive number of throwaway LineString/Polygon classes
every time the TIN is drawn or the memory overhead of
storing such LineString/Polygon objects in the TIN
itself.
Is this the most elegant way to go about things?
Should I instead refactor things such that the TIN is
represented at the Layer level with each TinFace being
a feature? Or perhaps a third option I havent thought
of yet. Im getting more familiar with the
JTS/OpenJUMP code base by the day, but Im not
confident enough to be sure Im taking the best tack.
Any input from JTS/OpenJUMP gurus would be
appreciated.
--Christopher
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
