[udig-devel] Coordinated work on rendering? (Was: Some questions on Lite

[Matthias Basler <Matthias.Basler@xxxxxxxxxxx>]

Hi developers

James wrote:
> No but as GeoWidgets needs a revised model within geotools I wanted to
> know if this helped and a fresh perspective always helps!

Before I aswer your comments, I want to throw into (yet) another general point
for discussion:
Obviously work on LiteRenderer has started ... much earlier than I expected
anything to change in the existing rendering architecture. This means that my
own requirements are not yet very well developed, except the more general
wishes. See
  http://docs.codehaus.org/pages/viewpage.action?pageId=31832

However this tells me that we should somehow coordinate our work on the
renderers, so we don't do it twice or more complicated than necessary.

There are several things obviously to be done to rendering:
- Clean up LiteRenderer to StreamingRenderer (short term)
- Make it work with a viewport model. (I'd like that
  but it is not urgent for me. I can use wrappers in the meantime.)
- Do rendering optimizations proposed on the RnD page (time frame unknown)
  (see http://docs.codehaus.org/display/GEOTOOLS/Rendering+Optimization=
- Backport uDig rendering framework and do really major changes (mid term?)
  This is, of course, the thing I am most interested in.

Now, please don't hit me for tinking about the following:
- How much sense does it make to include a viewport model now and/or create a
new renderer interface if, some months from now, the while rendering API will
get a major overhaul.
- I'd really like to see GeoTools, uDig and other GeoTools users share one
rendering API that satiefies their requirements. Rendering improvements would
then be shared by all users, and it would be something I would feel comfortable
to code against in GeoWidgets.
- Since, as I pointed out on my wiki page, the MapFramework API, Catalog API and
Rendering API are tightly coupled, my suggestion is that all the backporting
work of rendering and catalog classes is done at the same time. Additionally
this should be the time when the new MapFramework comes into use.
- Such big code change takes time, and it takes time to collect all the
requirements from all stakeholders involved. So my suggestion is to do it after
GeoTools 2.2.
I'd rather like that to be done well than early.
- Maybe this could give us the time to look into the GO-1 specification and
review if some concepts (e.g. Map Canvas and Graphics related ones) might be
interesting for us too, not to mention things like maybe switching from JTS
Envelope to GeoAPI Envelope a.s.o.,
- In the end it boils down to the question if you would prefer to do everything
in small steps (and maybe revise some packages twice) or if you would be
willing to do a major code change with all its consequences ... (and maybe end
up with a GeoTools 3.0.)

Whatever you prefer, I need some feedback on how you imagine the time table. How
much work in StreamingRenderer makes sense now?

--------

For your interest: I committed the prototype classes for the new MapFramework
(and related things like CatalogAPI and my ViewportState class I spoke about.
See
http://svn.geotools.org/geotools/trunk/spike/matthias/gt_mapframework

Feel free to play with the classes, send comment, edit them and so on.

--------
Now from my high flying ideas to your comments

> > I consider a solution somewhat inspired by the
> > IViewportModel object in uDig. I was able to write a prototype class,
> > called "ViewportState", that
> > - stores screenSize and current mapExtent (I used different names though)
> > - listenes to screenSize changes at its map widget
> > - computes map scale and total zoom*
> > - computes the worldToScreenTransform and it's inverse transform
> > - keeps all these things synchronized when the the screenSize, the map
> > center point, the map scale or the zoom factor* change.
>
> I do like the sound of this, would a member of the uDig team like to
> comment on the chances of a viewport model object living in GeoTools
> that would meet their requirements.

See my comment above: It would not take much coding to make StreamingRenderer
work with a viewport model, but I am not sure now is the right time to do this
change. It is not urgent for me and I have created a wrapper solution that uses
a LiteRenderer internally, although this solution does not not distinguish map
scale and zoom. It is just a bad workaround. But currently I don't need more.


> > [...] separating "map scale" and "zoom factor" in a map widget [...]
> The J2D renderer does something like this with the magnifier (I think)
Yes, the StyledMapPane has this functionality. I'll have to look at it to see
how they achieved this effect.

> but can the same effect not be achived with concatonating afine transforms?

Not sure what exactly you mean. I am quite sure LiteRenderer is not currently
suited to support this notion. It does not know the difference between
- a 1:50000 map, 5 times magnified and
- a 1:10000 map,
given the sparse input information it gets. But the SLD styling API does.

One thing is clear: Separating map scale and zoom factor in a widget and finally
combining both and sending the LiteRenderer the resulting transform only is like
casting pearls before swine.
But again, this is not urgent for me.

> Thanks for your comments and feedback, it is much appreciated.  The
> geowidgets project is, I feel, a very important one and I'd far rather
> see GeoTools modified to meet your needs than for you to have mad code
> to acomodate some of our peculiarities (mostly from old ideas that
> were never updated)

Thanks. [Blushing.] I hope I can live up to your expectations...

Jesse wrote on the "worldToScreenTransform" method:
> Actually James, LiteRenderer doesn't know the screensize.  The method is
> just a VERY commonly used method and could be moved to a utility class.
> There is no reason not to have it static as it stands.

My comments:
- Please no not include it into a Renderer interface
- It should live in the viewport model and, yes, it sould be static.
 (In my concept no object except the viewport model itself needs to do this
calculation. All external objects should just get the results from the viewport
 model instead of doing the calculations themselves.)

Please see my ViewportState prototype class at
http://svn.geotools.org/geotools/trunk/spike/matthias/gt_mapframework/src/org/geotools/java5/rendering/DefaultViewportState.java
and it's interface
http://svn.geotools.org/geotools/trunk/spike/matthias/gt_mapframework/src/org/geotools/java5/rendering/interfaces/ViewportState.java

Matthias Basler
c9bama@xxxxxxxxxxx

----------------------------------------------------------------
This mail was sent through http://webmail.uni-jena.de