Chris wrote: " I'm 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 don't know that you have too. You can still use a Layer with regular polygons that are the graphical representation of a TIN face, and which are stored in a normal a Layer. But maintain a separate object that actually represents the TIN, with its TINFace objects. This object representing the TIN might be all in memory, or it might be backed by a file. You then maintain a relationship between the Layer that is a graphical representation of the TIN, and the TIN object itself. So I don't really think you need to keep the TINFace objects "in" the Layer, you only need to keep their graphical representation in the Layer. I hope this makes sense... The Sunburned Surveyor On Thu, May 22, 2008 at 6:25 AM, Christopher <[EMAIL PROTECTED]> wrote: > > --- 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, I'm 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. I'm 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 I'm 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 > ------------------------------------------------------------------------- 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
