Hey Jody
Seems like we solved the problem associated with this. The issue and the
solution was as follows:
We were reading the BBOX in EPSG:32616 coordinate system, but when rendering
the ez image we were converting the bbox into EPSG:4326 coordinates when
creating the image. There must have been some kind of rounding off in our
function that converts UTM to Lat Long that caused the small shift.
Now we are using a common coordinate system i.e. EPSG:32616. I appreciate
the additional information you gave me. Atleast in our case it doesnt seem
to be any bug in geotools.
Thanks & regards
Ajay Ravichandran
On Mon, Jul 21, 2008 at 11:29 AM, Diez, Matthew <[EMAIL PROTECTED]>wrote:
> Jody (and others):
>
> I work with Ajay, and here is the (potentially) offensive code snippet:
>
> GridCoverage2D gc = curConfig.getGc();
> Envelope bbox = request.getBBox();
> double[] initSrcPoint = {bbox.getMinX(), bbox.getMaxY(),
> bbox.getMaxX(), bbox.getMinY()};
>
> // Assume UTM now
>
> // pack an empty array
> double[] finalPoint = {0, 0, 0, 0};
> GridGeometry gg = gc.getGridGeometry();
> MathTransform initialTransform = gg.getGridToCRS();
>
> //GridCoverageRenderer gcr = new
> GridCoverageRenderer(gg, null);
>
>
> try {
> MathTransform inverseTransform =
> initialTransform.inverse();
> inverseTransform.transform(initSrcPoint, 0,
> finalPoint, 0, 2);
> } catch (TransformException e) {
> getLogger().error("Unable to perform math transform
> on [" + geoTiffPath + "] Reason [" + e + "]");
> }
>
> Rectangle desiredSegment = new Rectangle();
>
> desiredSegment.x = (int) finalPoint[0];
> desiredSegment.y = (int) finalPoint[1];
>
> // Determine width and height based on nw corner - se
> corner
> // absolute pixel differences
> desiredSegment.width = (int) Math.abs(finalPoint[0] -
> finalPoint[2]);
> desiredSegment.height = (int) Math.abs(finalPoint[1] -
> finalPoint[3]);
>
>
> PlanarImage planarImage = (PlanarImage)
> gc.getRenderedImage();
>
> BufferedImage sourceImage;
>
> try {
>
> Rectangle2D rect = new
> Rectangle2D.Double(finalPoint[0],finalPoint[1],desiredSegment.width,desi
> redSegment.height);
>
> sourceImage =
> planarImage.getAsBufferedImage(rect.getBounds(), null);
>
>
>
>
>
> } catch (IllegalArgumentException iae) {
> // most likely requested image dimensions are not
> contained
> // in the image file
> getLogger().debug("Requested image dimension [" +
> desiredSegment.toString() + "] not found in planar image.",
> iae);
>
> return unshiftedImage;
> }
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Jody Garnett
> Sent: Friday, July 18, 2008 6:29 PM
> To: AJ R
> Cc: [email protected]
> Subject: Re: [Geotools-gt2-users] Issue regarding alignment of geotiff
> and postgis layer
>
> AJ R wrote:
> > Now coming to the issue we are facing. When the layers are rendered on
>
> > the map due to some weird inexplicable reason the 'ez' layer and
> > 'mapBackGround' layer do not seem to be aligning properly. There is a
> > slight difference in the rendering of the two layers. In addition as
> > we move from top left hand side of the screen to the bottom right
> > hand, the deviation increases. At higher zoom levels, the layers line
> > up almost exactly but not perfectly.
> Interesting.
> > Has any one ever faced a similar situation.
> I got a report of a similar problem (feature data and a MRSID file not
> lining up) three weeks ago - until I am able to reproduce the problem I
> was not going to annoy anyone.
> > If yes could you take a guess at where in the whole (PostGRes - WMS
> > server - GeoTiff renderer - PostGIS renderer - Mapbuilder/OpenLayer)
> > hierarchy could the problem lie?
> I suspect the raster resample code code - but that is only because it is
> how the problem was first reported to me.
> When we do a "resample" we actually take the inverse of the transform
> used by the feature data...
> DATA WORLD SCREEN
> Geometry -transform-> Geometry -transform-> Shape
> Image <-transform-> GridCoverage <-transform- pixel
>
> The Data to World MathTransform is based on the referencing moodule, and
> usually the EPSG database; you are using epsg-hsql or something?
> epsg-wkt may not be quite as accurate.
>
> So the kind of error you are talking about could be due to
> MathTransform.inverse() not being quiet as accurate as the origional. To
> test try setting up a MathTransform in each direction and see how close
> the transformation is in one of the areas you are having problem.
>
> The World to Screen is usually an AffineTransform and is going to be of
> similar accuracy in both direction.
> > Also could you let me know if there is a more effective way to render
> > geotiff files as compared to the general mechanism i suggested in the
> > Rendering section above
> You are using the resample operation right?
> > In case the above information is not helpful I would be glad to
> > provide more information. I would appreciate any help with this issue.
> We should report the bug; and if your data is not private some screen
> snaps showing the problem would be helpful.
> All the best,
> Jody
>
> ------------------------------------------------------------------------
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge Build the coolest Linux based applications with Moblin SDK &
> win great prizes Grand prize is a trip for two to an Open Source event
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Geotools-gt2-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
>
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geotools-gt2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
