It seems that there are currently only two paths to layers: Layer and
Layerable. Layer has been used for Geometry and Layerable (AFAIK) has been
used for image layers (WMS and SID). Either way you go, you will probably
be going where no one has gone before. If you are going to generate the
polygons on the fly from the TIN, I agree that Layerable is the way to go,
but you won't get much rendering help from the base classes, the Layer tree
panel will probably need some modification to support your new Layer type,
and you will have to figure out how to load and save the new Layer type.
Representing the TIN with regular Geometry objects would be much easier, but
perhaps less efficient.
regards,
Larry
On Wed, May 21, 2008 at 2:41 PM, Sunburned Surveyor <
[EMAIL PROTECTED]> wrote:
> 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
>
--
http://amusingprogrammer.blogspot.com/
-------------------------------------------------------------------------
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
