Christopher,
I would not extend Geometry for the TinFace, subclassing Geometry is not
something that works will in the current JTS code base. I would just
have a custom TinFace class which could be converted to Polygons if
required for some cases. I think in a lot of cases you can forgo the
conversion to Polygons. You could implement the CoordinateSequence
interface on the TinFace so you reduce the amount of objects created
when creating those polygons.
Likewise for GeometryCollection, I'm not sure if you gain anything by
being a GeometryCollection.
For JUMP integration having it wrapped in the only feature in a layer
doesn't add anything. Instead you could come up with an implementation
of the Layerable inteface for rendering of TIN's, This will allow you to
bypass all the conversions to Geometries and features. In this layerable
you could just select the TINFaces from the TIN by bounding box and then
render those as required. This might be a bit more work if you want to
support styling and selecting faces/edges in the TIn but I think it
would be a lot cleaner and you could add right click menu items specific
to a TIN.
Just my very quick thoughts on what I'd do in your place.
Paul
*Paul Austin*
/President/CEO/
Revolution Systems Inc.
+1 (604) 288-4304 x201
www.revolsys.com <http://www.revolsys.com>
Christopher wrote:
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 haven't thought
of yet. I'm getting more familiar with the
JTS/OpenJUMP code base by the day, but I'm not
confident enough to be sure I'm 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
-------------------------------------------------------------------------
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
