[Geoserver-devel] WMS/lite and highly deformed bboxes

GeoServer GeoServer Developer
1

I made a small change to lite renderer.

Instead of using the JTS.transform(Envelope,...) function to create a
query envelope in another CRS, it now first densifies the envelope
(into a "box" polygon) and transforms that. The end result is a
"larger" bounding box search.

If you were using a highly deformed bbox (for example looking at the
entire USA in a BC Albers projection), you would find that features
wouldnt be drawn because they were never retreived.

The end result is a larger query bounding box and a correct map.

JTS.transform(Envelope,...) -- transforms only 2 points; the lower right
and upper left corners (not the other 2 corners).

dave

envelope = JTS.transform(envelope, transform,10);

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

2

dblasby@anonymised.com wrote:

I made a small change to lite renderer.

Instead of using the JTS.transform(Envelope,...) function to create a
query envelope in another CRS, it now first densifies the envelope
(into a "box" polygon) and transforms that. The end result is a
"larger" bounding box search.

Nice but... as far as I remember, this is not the exact solution. Reprojection classes could,
last time I checked, get a Shape implementation and reproject it creating exact (curved)
reprojected lines. So the most accurate solution should be to get the box, reproject it
as a Shape, and then get the bounds2d of the reprojected shape.

Hope this helps
Best regards
Andrea Aime

3

Andrea Aime a écrit :

Nice but... as far as I remember, this is not the exact solution. Reprojection classes could, last time I checked, get a Shape implementation and reproject it creating exact (curved) reprojected lines. So the most accurate solution should be to get the box, reproject it as a Shape, and then get the bounds2d of the reprojected shape.

There is a MathTransform2D.createTransformedShape(Shape) which expect a Java2D shape and returns a new (transformed) Java2D shape.

In pure ISO style, there is also a Geometry.transform(...) method. This one is more generic (since it is not strictly 2D) and part of ISO specification, but not yet implemented in Geotools.

In current Geotools implementation, only the Java2D method is implemented. However, the default implementation has some approximations too:

   - We have not yet investigated the mathematic behind an exact
     analytical solution for projected curves. I suspect that it
     would not be trivial (I guess some good book must exist).

   - Current Geotools implementation computes 3 points (the first
     and the last one, and a middle point) and fits a quadratic
     curve through those 3 points. It should be exact if we assume
     that any straight line become a quadratic line (or an other
     straight line, which I consider as a particular case of a
     quadratic line with the coefficient of x² set to 0) after the
     projection. I don't know how accurate this assumption is.

   - If we want yet more accuracy, we could fit a cubic line instead
     of a quadratic line (we would then need 4 points instead of 3).
     But it would require more mathematical background, or a good book
     with formulas written for us.

   - Java2D's Shape.getBounds2D() is itself approximative in the case of
     quadratic and cubic lines. As of J2SE 1.5, it doesn't (yet) returns
     the smallest bounding box, but returns instead a box which contains
     the control points. See:

     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4225281
     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851378

However, the "curved lines" approach still probably a better approach in the long run, since:

   - We may improve the curve fitting accuracy over time.

   - It is probably more efficient, since it transforms only 1 more point
     (in addition to the vertex transformed anyway) and performs all
     other computations (e.g. bounding box) analytically.

  Martin.