David Blasby ha scritto:
(sending this out quickly for the IRC meeting)
Okay, I've been fixing up the StreamingRenderer the last little while,
and here's what I think needs to be done. Most of these are just little
clean-up to get rid of the evidence of a long period of people slapping
stuff into it.
A) The path through the renderer is a bit confused. For example, where
is CRS transformation done? Its actually done by wrapping the
FeatureReader in a CRS-transforming feature reader. But, there's also
code (now in LiteShape2 - it used to be partially in LiteShape2 and
partially in the Graphics2D segment Iterators) that takes a geometry,
decimates it, transforms it,then does a pixel-level generalization. The
CRS transformation code should be done here since you can save a bunch
of complex math by generalizing first. Its also just really confusing
to read since there's 3 sets of generalization code! There's other
cases of confusion.
By all means, reproject only after decimation. It's very very slow to do
that before decimation. Reprojection in feature readers is thought for
people that actually have to use the geometry in some kind of spatial
analysis or editing, and need it in a different CRS, it was never intended
for rendering.
B) All the Graphics2D Iterators need to be re-written. I just rewrote
the LiteIterator (which can get re-used by all the other Iterators).
The Iterators are extreamly difficult to read.
Once (A) is done, this should be much easier since they seem to be
"doing too much" right now.
I don't know the current state, but last time I commited them, they
were doing exactly what needed: decimate, reproject and iterate.
Remove one element and you'll pay quite a performance hit. If you like, you
can move decimation and reprojection in another class, but never reproject
before decimating.
C) The renderer should be segmented into two classes. The first one
should be concerned with "setting things up". These are things like
dealing with the MapContext, optimizing the styles, getting optimized
FeatureReaders. The second will basically take the FeatureTypeStyle[]
(which has the Graphics2D and actual Styles) and FeatureReader and do
the actual drawing. This break is currently in the Renderer
approximately at the function "processStylers()"/"processSymbolizers()".
This will allow for more code-reuse, and simplify the current (giant)
class. Its not too much work since the renderer is conceptually already
broken up like this. It will make it very easy to write a parallel
renderer that would render more than one layer at a time (good for
multiprocessor machines and/or datasets that block while reading from
the disk/network/socket).
Yes, good idea. Well, ideally it should be broken in three, and have
data stores provide directly Java2d shapes instead of JTS geometries (plus
a wrapper class that does the transformation for datastores that can only
generated JTS geometries). Ideally, this should remove the need for a
special ShapefileRenderer, if you see what I mean.
The end result will be a renderer that is much easier to understand and
maintain. I'd bet there will be minor speed improvements too.
Anyone got any time to help in this?
Not at the moment, sorry. I'm still playing on UMLGraph :-(
Cheers
Andrea
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
