Only rendering 1/2 geotiff

Andrea Aime added a comment - 07/May/11 9:08 AM There is a quick way to tell: set the RESAMPLE_TOLERANCE global hint to 0 and see if the problem goes away. Regardless of there reason, where can I get the data? Hopefully the same issue can be reproduce in GeoServer, if not, I'll need a Geotools self contained example to reproduce.

Jody Garnett added a comment - 08/May/11 8:35 PM The data (for almost any udig issue) is based on the sample data used for the project: - http://udig.refractions.net/confluence/display/EN/Walkthrough+1 - http://udig.refractions.net/files/data/data_1_2.zip

Jody Garnett added a comment - 08/May/11 9:10 PM I tried it as a normal rendering hint:                 // JG: control geotools rendering                 graphics.addRenderingHints(hints);                 hints.add( new Hints( Hints.RESAMPLE_TOLERANCE, 0.000000000001 )); And for 0 got: rendering java.lang.IllegalargumentException: 0 incompatible with RESAMPLE_TOLARANCE The default was 0.33; so I have tried 0.033, 0.000000000001 and the result gets better (the middle of the raster is rendered and the amount shown improves). Changing it to 0.5 made the problem worse (only getting a smaller stripe of the image). Matching the CRS makes the issue go away (so the workaround is still fine).

Andrea Aime added a comment - 21/May/11 11:50 AM Found the issue, it's the fix for GEOT-3413 that happens to introduce a larger bug than the one it's trying to fix. When the transformation is a pure translation with values very close to an integer (as in, very very close) JAI might throw random exceptions, the fix force the usage of a well behaved translation operation... using the shear factors instead of the translation ones! This results in the image being out of place.

Andrea Aime added a comment - 21/May/11 11:58 AM Jody, I think I've fixed it with the last commits. In your case I believe the reprojection is just aggravating the base issue, but I cannot be sure. Can you try it out and see if uDig renders the coverage properly? After the commit GeoServer does, but the code paths used by the two application is different

Jody Garnett added a comment - 25/May/11 8:21 AM Same trouble; slightly different look

Andrea Aime added a comment - 25/May/11 9:08 AM Btw, to set the resampling tolerance to zero just use 0.0, it has to be a double not an int (that's why you get that error message about about the incompatible value)

Jody Garnett added a comment - 30/May/11 7:59 AM I was able to reproduce this glitch with a slight modification to the normal ImageLab. 1. Add a line to set the map crs to be the shapefile crs 2. Let the application load (it shows nothing) 3. Click zoom to extent I have attached the modified ImageLab, and a picture of the result.

Andrea Aime added a comment - 12/Jun/11 10:02 AM Jody, I see you're getting organized to work on this one. I might have done different choices but no problem, go for it. Just remember to check for a review before you commit on the coverage modules.

Jody Garnett added a comment - 12/Jun/11 7:57 PM Well I was going to fix the bounding box situation and reduce the amount of duplicated code; actually changing gt-coverage I was going to leave to you :-) I am kind of searching for easy bugs to use as introduction / training; this one is not an easy bug (so I have set up GEOT-3641 for that role). I will sort out something for densification in the CRS class; and then assign this back so you can review and roll out to gt-coverage. I do note that the contract for the CRS.transform methods is not consistent with respect to "reuse" of the supplied target envelope (I can pass in an Envelope2D and get a GenericEnvelope back).

Andrea Aime added a comment - 13/Jun/11 2:16 AM Hum. ok, assign the issue back once you're done with the preparations you want to do. I'll have a look at it as spare time allows.

Paul Pfeiffer added a comment - 17/Aug/11 2:50 AM A patch for shrinking an envelope transform to the valid extent of the crs

Paul Pfeiffer added a comment - 17/Aug/11 3:21 AM It would be helpful if someone could take a look at the above patch and give me some feedback. Ok... I looked at the data being sent to the transform in the imageLab example and it is actually passing in an envelope that is outside the valid range of the CRS eg [-179.99999999995 -90.000000000005, 180.00000000005 120.99999999995]. So if (-180<=longitude<180) the maths transform gives a mathematically correct result and assumes that the longitude loops back into the valid range. Also if the latitude is outside the range of -90 to +90 then the maths transform dies and usually sets the longitude to 0... Hence giving the half image. The above patch should fix this issue by shrinking the transformed envelope to be within the valid range of the crs. It also allows for a crs in meters. All the test cases in crsTest pass but I'm not sure if I've caused other problems because I've currently got some issues with my gt-swing package. Also I haven't yet checked if this issue occurs at other locations but I thought I would wait on some feedback before going any further.