Chris, You've asked some good questions, and I'm glad Paul got back to you a lot sooner than I did.
Paul wrote: "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 agree with Paul on this point. Geometry isn't really meant to be subclassed. I should have mentioned this to you before but didn't think about it. Paul wrote: "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." Implementing Layerable probably is the most elegant way to go about this. However, I'm not sure how rendering of Layerable implementations works. I don't see any methods defined in the Layerable interface that would be used for actual painting of the TIN. on the contrary, the Layer class makes a getStyle method available. The paint method of the Style class can then be used to render the contents of the Layer. So implementing Layerable will be more elegant, but may require some tweaks to enable Rendering. Storing polygons in a regular Layer as representations of TIN faces means we don't have to worry about rendering, but the solutoin is probably less elegant. Storing the TIN faces as polygons in a regular layer is that normal editing/analysis tools for layers will work for the TIN faces. This could be an advantage or disadvantage depending on the circumstances. If could be a nightmare to synch the underlying TIN faces with the Polygons displayed in the LayerViewPanel. If you decide to go with the implementation of Layerable I can work with you on what we need to do to get the Tin to render. We might also check with the creators of the SIDLayer, who I noticed also implemented Layerable interface. Landon On Tue, May 20, 2008 at 3:40 PM, Paul Austin <[EMAIL PROTECTED]> wrote: > 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 > > 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 > > ------------------------------------------------------------------------- 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
