--- Sunburned Surveyor <[EMAIL PROTECTED]>
wrote:
>
> P.S. - Chris: If Paul's modifications to OpenJUMP
> work the way I
> think, then we won't have to make changes to
> OpenJUMP's rendering
> system to add rendering for a JTin layerable as was
> stated previously
> in this thread. Having said that, I think it will
> still be easier to
> use normal JTS geometries and a regular Layer.
>
Regardless of what level I target, Im going to need a
TIN class that contains all the related methods for
querying and traversing the TIN (things like
extracting elevation bands, viewshed matrices,
hydrology information, etc). All that will depend on
a TinFace class that includes links to neighboring
faces and the three vertexes. Im uneasy about using
LineString or Polygon as the internal representation
for the TinFace because they will store four vertexes
instead of three, which given the memory limitations
of Jump, would severely limit the size of the Tin that
could be used.
I like the idea of staying only at the Layer level
because of the freedom it offers. If I can make it
work, I will be able to do some really cool rendering
and storage stuff in the future that would be more
complicated when done at the Geometry level (things
like fast 3D display within the JPanel, seamlessly
integrated database/file backed multi-resolution mesh,
and a few other ideas Im kicking around).
Well, back to reading code, I need to get as good of
grasp of Layers as I have of JTS...
Thank you everyone for your input, it has been
invaluable.
--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
