Landon,
The difference was that the old Renderer.ContentDependFactory only
passed in the layerable object to render so you didn't get access to the
LayerViewPanel so rather than breaking code which used the old method I
added the new one.
It was added in December last year.
Paul
Sunburned Su
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 to
--- 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 th
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 ad
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 s
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
polyg
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
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
c
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 Ge
