Raster datasets with worldfiles sometimes not placed correctly

Logged In: YES user_id=1799 Se corresponde con el ticket del iti 2829 Reported by bducke in date 2010-01-14

Logged In: YES user_id=1799 2010-01-14 changed by bducke attachment geotiffs.zip added. -------------------------------------------- 2010-01-14 changed by bducke GeoTIFF and worldfiles -------------------------------------------- 2010-01-14 changed by vagazzi build changed from 1254 to 1253 -------------------------------------------- 2010-01-14 changed by vagazzi Hi first I think that if parameters are not the same in both files the position should not be the same. Moreover both tfws differ on 2 meters on the X position and a half meter on th Y position so I think that the origin of both rasters data should differ at least 2 meters. I meassured the displacement on the 1.9 version and it"s almost 0 8 meters so there"s something wrong. -------------------------------------------- 2010-01-14 changed by bducke attachment tfw-calc.ods added. -------------------------------------------- 2010-01-14 changed by bducke Calculation of geolocations for pixel coordinates of same object in both tifs -------------------------------------------- 2010-01-14 changed by bducke I know the tfw parameters are different. However look at the actual TIF images. You will see that one is rotated (this is the one that gets placed correctly) and one is not (that"s the one that gets placed wrongly). Now if you use an image editor and grab the pixel coordinates of an identical object in both raw tif image files then calculate the geo coordinates from the .tfw parameters you should get the same coordinates for both datasets. But you don"t (at least not in gvSIG 1.9. It"s OK for example in ArcMap). For demonstration purposes I have attached an Open Office Calc sheet with the tfw parameters for both files. You can insert pixel coordinates into cells B6 C7 to see for yourself the differences should be tiny (bold cells D6 E7). I used the pixel coordinates of the center of the DP 90 034.3 marker for an example. -------------------------------------------- 2010-01-28 changed by bducke I think I have found the problem. The image data in the TIF file 90034.tif is rotated by 180 deg. Upon loading the data gvSIG rotates the TIF image correctly but it does not rotate the corresponding georeferencing data in the the .tfw file This bug is new with gvSIG 1.9 and extRaster-SE. The old raster code in gvSIG 1.1.2 handled this correctly Try the two images in my original ZIP attachment with gvSIG 1.1.2. They will display in almost exactly the same location (the georeferencing for the two images has a difference of a few cm). -------------------------------------------- 2010-01-29 changed by rsoler Hi Ben What we did to test if gvSIG 1.9 was doing the transformation correctly was taking the X Y pixel applying the tfw parameters and calculating the X Y geo as you did in your ods. The X Y geo obtained are the ones that gvSIG 1.9 is displaying so we think that"s the expected behaviour. -------------------------------------------- 2010-01-29 changed by bducke Yes the georeferencing is correct. But only """before""" gvSIG 1.9 rotates the image data. After that the georeferencing no longer matches the rotated image data which leads to the location offset. I have tried the same GeoTIFFs in gvSIG 1.1.2 QGIS 1.4 and ArcGIS 9.3 running several different versions of GDAL. They all did it correctly. Only gvSIG 1.9 produces a different result. There are two possibilities here either gvSIG 1.9 does it correctly and all the other GIS are wrong or the other way around. -------------------------------------------- 2010-02-03 changed by pmercade owner changed from pmercade to nbrodin -------------------------------------------- 2010-02-12 changed by bducke Has there been any progress made on this issue I am currently training people on using the new gvSIG georeferencer and this bug makes it very hard to convince them that gvSIG is usable. The georeferencing and transformation (affine) are applied correctly but the rasters are definitely misplaced whenever a rotation is applied to the image data. They are placed as expected in QGIS. Also there is a display corruption effect associated with this zooming into the raster image the left edge will be cut off and become invisible. I am assuming this is because of the mismatch in location information. This is getting very very frustrating for me. I have been advertising gvSIG to a lot of people but rectifying images and digitizing on top of them is a very basic procedure and I now have to tell people to use QGIS or continue using the old version of gvSIG. I will attach a raster with control points in RMF format to this ticket. Please see for yourselves load it into the georeferencer start an affine transformation load the control points from the RMF file. You will see that they are all fine within an accuracy of about 20 cms. Then apply the georeferencing and check the coordinates in the transformed raster they are almost 2 m off now load the same georeferenced raster into QGIS it will transform it correctly -------------------------------------------- 2010-02-12 changed by bducke attachment 90107.jpg added. -------------------------------------------- 2010-02-12 changed by bducke Example image for georeferencing -------------------------------------------- 2010-02-12 changed by bducke attachment 90107.rmf added. -------------------------------------------- 2010-02-12 changed by bducke ... and the control points to go with it -------------------------------------------- 2010-02-12 changed by bducke I have attached example image 90107.jpg and the corresponding RMF. -------------------------------------------- 2010-02-12 changed by bducke attachment screenshot-01.png added. -------------------------------------------- 2010-02-12 changed by bducke Effect of Zoom to layer raster is displaced to right of View"s center -------------------------------------------- 2010-02-12 changed by bducke attachment screenshot-02.png added. -------------------------------------------- 2010-02-12 changed by bducke Effect of zooming into the layer raster is displaced and image data cut off -------------------------------------------- 2010-02-12 changed by bducke I have attached two illustrations of the effect that this bug has on affine transformed raster layers. As you can see the Zoom to layer does not result in properly centering the image data in the View. Also when zooming in on the layer image data is cut off. I suspect this is because there is a mismatch between the extent of the actual raster data and that of the georeferenced extent. -------------------------------------------- 2010-02-15 changed by bducke I have done more tests and I know now that the bug hits whenever the control points for the affine transformation are rotated more than 90 degs (in any direction) against the View"s coordinate system axes. It does not hit if the control points are only rotated against the image data"s X and Y pixel axes. Rotation of the image data itself works in all cases. So I am pretty convinced now that it is a problem with calculating the raster"s buffer extent in the active data View. I am now looking into libRaster src org gvsig raster grid render Rendering.java and the function request() as I suspect it returns wrong buffer coordinates in those cases. -------------------------------------------- 2010-02-15 changed by bducke OK I am getting closer to finding the bug. Turns out the problem is not the calculation of the buffer extent. That works fine. The problem is that the raster renderer seems to choose a wrong rotation origin point in some cases. The relevant code in Rendering.java starts here if(transf.getScaleX() 0 transf.getScaleY() 0) There are four cases being checked that generate four different rotation point positions. My feeling is that the checking fails if the rotation becomes 90 degrees. It"s probably something to do with - signs. -------------------------------------------- 2010-02-15 changed by bducke Yes. That"s indeed the problem. The rotation point is bad for some combinations of pixel signedness and rotational factors. I have managed to find some corrections. Will post a bug fix when I am confident I fully understand why things are working now. -------------------------------------------- 2010-02-18 changed by bducke OK fixed it. The problem was that for some rotations a translation in X or Y direction needs to be applied to the rotation point. The correct values for this can be read using the transformation objects getTranslateX() and getTranslateY() methods. Instead of guessing the rotation point coordinates from the X and Y pixel signs as it is done now the proper way to get the rotation point is to use this simple line El punto sobre el que rota la imagen depende del signo de los tamanos del pixel pt new Point2D.Double(transf.getTranslateX() transf.getTranslateY()) --------------------------------------------