Paul, This is a topic of interest to me, since I did some work on pluggable rendering in OpenJUMP a year or two ago.
You said that: "Create your renderer class for your sub class of layerable then register it to be used to render instances of that type." When was the setRendererFactory class added to OpenJUMP? Did you commit this change 5 months ago? Why replace the putRendererForLayerable method with a similar method having a different signature? How do the methods differ? I'm also curious when the putRendererForLayerable method was added, since I don't see it in the original JUMP code for the RenderingManager class. Were they both methods you added? I'm asking about this because I didn't run across these methods when I decided to implement pluggable rendering myself. I'm also curious how your implementation works. Can you register a renderer from a Plug-In with the new pluggable rendering system? If your work is already committed and it is functional I may scrap my pluggable rendering code for OpenJUMP. Landon 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. On Wed, May 21, 2008 at 2:38 PM, Paul Austin <[EMAIL PROTECTED]> wrote: > 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 > > 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 > > ------------------------------------------------------------------------- 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
