Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [udig-devel] Re: [Geotools-devel] Rendering and UDIG -- Sanity Check 
Hi Martin/Jessie:
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),
We love your J2D renderer - it is very close to what we want to have. What we would like to do is throw a few more months of development into it (and not another rewrite from scratch).
The only downside to it being complex is that we are having difficult wrapping our heads around it and setting it up for our use. 
Let me Try some suggestions/questions:
- keep our "user's model of layers" on the application side and set up the j2drenderer to handle rendering each and everytime things changed Down side to that is that j2d error messages will need to be adjusted back into user space - Lack of WMS support - we will proabably need to add some sort "Grid with Event" support into j2d - Duplication of reprojection code between DataStore and J2D - not sure how to call this one - Event propogation from DataStore - does j2d listen for featureChanged events at this time? 
-
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.
Wow you lost me, are you culling the points before reprojection? Maybe back tranforming the bbox? 


  - It is capable to transform straight lines into curves for some kind
   of lines.


That is very cool.
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.
You are total right Martin - we just need to have a much better handle on what you have there - or we are going to end up reinventing the wheel. 

Jody
clear distinction between the request, view and data. That was one of our 

But it seems to me that this distinction already exists...
  - Data are ISO 19107 objects or Features.


Sorry I still doing speak ISO yet - do you mean Grid Coverage or Feature?


  - I guess that request are Query objects.


And it is going from one to the other that is causing grief.
Right now a FeatureSource was being cached to service the request, what I was looking for was just keeping the Query and looking up the FeatureSource/GridCovergeExchange. 


  - 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.
Thanks Martin - links like those above are exactly what we need right now. I will try and read up before the IRC meeting. 

Jody

Back to the top