GeneralEnvelope transform using densification
---------------------------------------------
Key: GEOT-3634
URL: http://jira.codehaus.org/browse/GEOT-3634
Project: GeoTools
Issue Type: Sub-task
Components: api, referencing
Reporter: Jody Garnett
Fix For: 8.0-M1
Attachments: ReprojectEnvelope.png
>From aaime's email:
{panel}
Now, when it's time to reproject an envelope the vector code does:
{code}
referencedEnvelope.transform(targetCrs, lenient);
{code}
This is actually the most advanced envelope reprojection code we have. If first
gets the CoordinateOperation from source to target crs, calls onto
CRS.transform(operation, envelope), and then takes into account five extra
points per side to account for reprojecting bending and "bubbling" the sides.
First off, CRS.transform(operation, envelope) is a smart method that can take
into account degenerate cases like people asking to reproject [-300, -150, 300,
150] in WGS84 to something else, the code will recognize the source crs is
geographic and compensate for the absurd request considering the whole world as
the source (if you roll -300, -150 it becomes -120, -30).
Then the densification, by default 5 extra points per side, takes care of the
cases in considering just the point by point reprojection would result in a
smaller bbox than actually needed (see attached picture).
So ok, vector code is good.
Most of the raster code does instead this:
{code}
MathTransform mt = CRS.findMathTransform(source, target, true);
GeneralEnvelope ge = CRS.transform(mt, sourceEnvelope)
{code}
This approach is unfortunately piss poor instead:
* the math transform does not carry around source and target CRS,
(CoordinateOperation would) so there are no smarts to correct "larger than
world" requests
* there is no densification going on
As a result we get GEOT-3570, the code is trying to envelope a larger than
world envelope in NAD83 back in WGS84, coordinate rolling happens, and we end
up with a much smaller than world area, thus the missing parts in the rendering.
Adding insult to the injury, that smaller area is used to select the overview
in the tiff file, making the code think we are actually much more zoomed in
than we are, thus getting a much higher resolution overview: not only a wrong
result, but also slower!
To fix this we have to get the coverage code either call
{code}
CRS.transform(envelope, targetCRS) or
CRS.transform(coordinateOperation, envelope)
{code}
Given the code is setup to extract a MathTransform already it's probably easier
to add a CRS.findCoordinateOperation(source, target, lenient) method and then
have the coverage reader code around use CoordinateOperation instead of
MathTransform, getting
the math transform out of the coordinate operation as needed. Though in many
cases we can just go straight for CRS.transform(envelope, targetCRS)
Now, that is not so hard, but there are 65 points in the code base calling
CRS.transform(mathTransform, envelope) plus 6 calling the
CRS.transform(mathTransform, sourceRectangle,
targetRectangle)
Soo.. it's not a small change.
I'm up to do it, but I think I'll need some review.
Since this is bug fixing I'd like to backport the results to 2.7.x
Mind though, this would only solve part of the problem, since even
CRS.transform(envelope, targetCRS) does not do the densification. I guess we
also want to add the densified reproject code into CRS, and have
ReferencedEnvelope (and the JTS utility class) use it instead.
{panel}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
