Chris,
I have some examples on adding your own renderer. The example displays a
regular grid on the map and allows you to zoom to a mapsheet grid cell
by name.
You can get the source for my plugins at
http://rsiaf.googlecode.com/svn/rs-jump-core/trunk/
Create your renderer class for your sub class of layerable then register
it to be used to render instances of that type.
RenderingManager.setRendererFactory(GridLayer.class,
new GridRendererFactory());
You can add a pop up menu using the following.
JPopupMenu gridLayerPopupMenu = new JPopupMenu();
workbenchFrame.getNodeClassToPopupMenuMap().put(GridLayer.class,
gridLayerPopupMenu);
The look at the following classes to see what I'm implementingm, you'll
need to customize the rendering for TIN's
com.revolsys.jump.ui.model.GridLayer;
com.revolsys.jump.ui.model.GridRendererFactory;
com.revolsys.jump.ui.model.GridRenderer;
Hope this helps.
Paul
*Paul Austin*
/President/CEO/
Revolution Systems Inc.
+1 (604) 288-4304 x201
www.revolsys.com <http://www.revolsys.com>
Sunburned Surveyor 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
-------------------------------------------------------------------------
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
