Andrea Aime a écrit :
> Sorry, my understanding of Rob proposal was that everybody should use
> long/lat axis order internally.
>
> This would have scary performance consequences on both rendering and
> WFS serving because the data stores would have to provide data in
> that order, maybe just to re-swap them again if the required CRS
> for output is swapped again... (hint: on rendering we do reproject
> after decimation, so we do reproject just a minimal part of the
> original points).
>
> I know having to deal with axis swap is complicated on the source
> code level, but forcing an order on the data store has its problems
> too.
I can't speak about the WFS side. But on the rendering side, the cost should be
very low (if any).
The operation chain (as implemented in the legacy StyledMapPane or the GO-1
renderer) is to define a
"display CRS", which is the CRS of the output device (well, not exactly that,
but close). For
example the "display CRS" for the screen is a CRS with (x,y) axis, where the y
axis is oriented
toward the bottom. Then, we can use:
CoordinateReferenceSystem objectiveCRS = ... e.g. the Mercator projection
...
CoordinateReferenceSystem displayCRS = ...
MathTransform objectiveToCRS = opFactory.createOperation(objectiveCRS,
displayCRS).getMathTransform();
In many case, this "objectiveToCRS" math transform will actually be an instance
of AffineTransform.
The referencing module manages all the dirty tasks (axis flipping, etc.),
including the reverse Y
axis direction for the screen device output. All those tasks (axis flipping,
objective to display
conversion, axis direction reversal, etc.) are contatenated in a single affine
transform. This is
why the axis swapping is usually free - we end up with a single AffineTransform
anyway, only with
different coefficients.
All the above may sound a little bit complicated and not very praticable. In my
refactoring of
J2D-Renderer as a GO-1 implementation, I tried to separate the various tasks
previously managed by
one huge Renderer class. All the CRS handling described above is managed by
ReferencedCanvas, which
doesn't do any rendering: its job is only to manage the dirty CRS handling for
subclass.
ReferencedCanvas is to be extented by (potentially many) renderers. We plan at
least two distincts
renderer, a 2D and a 3D one.
Will the GO-1 renderer is not yet there, ReferencedCanvas is complete and has a
working test suite.
So my point is that StreamingRenderer could (if they wish) extends
ReferencedCanvas in order to get
some parts of the dirty CRS stuff managed automatically by it.
Martin.
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
