I've been having a look at this issue... In summary (if I understand
correctly), there are occasional situations where a CRS transform (and
perhaps other maths transforms) results in an envelope coordinate
falling off the edge and the envelope ends up being about half the
size it should.

In the jira issue Jody posted a test which I copied over to
ReferencedEnvelope with a few changes and found that the issue occurs
here as well.


    /**
     * Test "densification" during envelope transform in order to
avoid clipping(GEOT-3634).
     */
    @Test
    public void testEnvelopeTransformClipping() throws Exception {
        final CoordinateReferenceSystem source = DefaultGeographicCRS.WGS84;
        final CoordinateReferenceSystem target;
        target = CRS.parseWKT(
            "GEOGCS[\"GCS_North_American_1983\","+
            "DATUM[\"North_American_Datum_1983\", "+
            "SPHEROID[\"GRS_1980\", 6378137.0, 298.257222101]], "+
            "PRIMEM[\"Greenwich\", 0.0], "+
            "UNIT[\"degree\", 0.017453292519943295], "+
            "AXIS[\"Longitude\", EAST], "+
            "AXIS[\"Latitude\", NORTH]]");
        // bounds from geotiff
        ReferencedEnvelope geotiff = new ReferencedEnvelope(source);
        geotiff.include(-179.9,-90.0);
        geotiff.include(180.0,89.9);

        Envelope transformed = CRS.transform(geotiff, target ); //<-------------
        assertNotNull( transformed );
        assertTrue( "clipped
y",transformed.getUpperCorner().getOrdinate(1) > 88.0);
        assertTrue( "clipped
y",transformed.getLowerCorner().getOrdinate(1) < -88.0);
        assertTrue( "clipped
x",transformed.getUpperCorner().getOrdinate(0) > 170.0);
        assertTrue( "clipped
x",transformed.getLowerCorner().getOrdinate(0) < -170.0);

    }




I looked into CRS.transform(Envelope, CoordinateReferenceSystem) and
it does a tranform(CoordinateOperation, Envelope) on about line1189

this method then gets the maths transform from the coordinate
operation and does a transform(MathTransform, Envelope,
GeneralDirectPosition) on line 1349

It appears to me that this method (line 1221) goes through and
transforms each point of the envelope along with the middle points of
each edge and finally the center point. (I can't quite figure out the
exact logic of the while loop and the the remainder after division
switch but after a few sysouts I can see that it produces the right
number of points)

So... what I can't figure out is.... Does the maths transform of each
point result in some of the points falling off the edge? (180.04999,
-90) ==> (0.4999, -90)
Or... have I just missed the boat completely?

Cheers
Paul Pfeiffer

------------------------------------------------------------------------------
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to