Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[udig-devel] Re: [Geotools-devel] Rendering and UDIG -- Sanity Check 
jeichar@xxxxxxxxxxxxxxx a écrit :


Now that we (udig) have something of a design for our system.   I want to
request a sanity check.  Does anyone have any thoughts on how we should use the
Lite and j2d renderers.  For example: how big a project do you think it will be
to fit the existing renderers into our design?  The current idea is to modify
them to make a "Renderer Pipeline."   More likely we were going to split them
into a "Feature Rendering Pipeline" and a "GridCoverage Rendering Pipeline."

I agree that j2d is a good renderer but it seems to me that some substantial
changes still need to be made in order to match our requirements.
It is true that it may requires substantial changes. But I fell that lite-renderer would need substantial *development*. J2D renderer is more than 1Mo of source code; lite-renderer is about 180 ko. J2D renderer is very complex, this is probably its biggest problem as I see it. But maybe there is a reason why it is so complex. The development for this renderer started in 1997 and have at least 8 full time months of work in it, including at least 2 rewrite from sratch. I know I'm defending my baby (so I'm not objective), but I don't think that an other renderer without projection or cache capability could be bring to that level easily. For example on reprojection: just transforming a Geometry before passing it to lite-renderer would work, but J2D renderer do more than that: 

 - It generalize the geometry (i.e. apply a decimation) according the
   current scale *before* to project the coordinates on the fly.
   Concequently, there is much less points to transform --> faster
   rendering.

 - It is capable to transform straight lines into curves for some kind
   of lines.
J2D renderer may needs improvement on startup time (and I have some idea on this matter) and refactored in order to simplify it. But once started, it should be the fatest. It is the most qualified for meeting requirements like "Zoom in less than 2 seconds". It has mapscale, status bar with mouse coordinates in arbitrary CRS, the capability to display rapidly a grid of arrows (e.g. winds), etc. It it capable to detect which geometry is under mouse cursor. A patch for selection is already available and is in the process of being incorporated in the code base. I don't think that adding those capability from scratch will be fast an easy. 




Keep in mind that one of the most important requirements is to have a clean and
clear distinction between the request, view and data.  That was one of our
focusses when came up with the design on the UDIG wiki:
http://docs.codehaus.org/display/UDIG/Home


But it seems to me that this distinction already exists...

  - Data are ISO 19107 objects or Features.

  - I guess that request are Query objects.

  - Views are RenderedLayer (or Graphic in GO-1 terminology).
    The name "RenderedLayer" see it all... This is a view of some
    kind of Layer. They *wrap* data, they do not contains data
    themself.
Please take a look at GO-1 for a renderer design. It is far from perfect, but it is probably better to take them in account than going in yet an other completly independent design: 

All org.opengis.go.* packages there:
http://geoapi.sourceforge.net/snapshot/javadoc/overview-summary.html
At the very least, instead of picking one renderer and eliminate the other, we should probably try to uses interfaces. And this is exactly what GO-1 attempt to provides. 

	Martin.

Back to the top