Re: [Qgis-developer] Georeferencer produces wrong (shifted) result
Hi Agustin, The points are correct (therefore the errors etc), but the georeferenced image is shifted. May be the datum is not taken into account when the georeferenced image is created. I did a clean checkout, and could finally reproduce the problem: it stems from the fact that your input file has a geotransform, which flips the yaxis of the local coordinate system and changes the origin. As the geotransform plugin does not handle geotransform info correctly, this results in the shift you have observed. Removing the geotransform (e.g. using gdal_translate -co PROFILE=BASELINE - of GTiff Ilerfly125v2.tif Ilerfly125v2-nogeotrans.tif) should give you a file which the georeferencer can handle correctly (you may have to delete the accompanying .aux file, if gdal uses this to keep the geotransform). I had a local patch in the georeferencer which handles geotransform information, so this is why I couldn't reproduce the problem (talk about a mixture of good and bad luck :-)). I will see what is required to make my local changes ready for submission, so we can avoid such subtle problem with georeferenced/pseudo-georeferenced files in the future. As I already mentioned, due to an important deadline at work, I have little time to dedicate to this atm, so it may take a few day... is there a release in the pipeline? cheers, Manuel ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Georeferencer produces wrong (shifted) result
Very good idea.. Implementing a known problems per release seems possible to me. But it can only be a webpage cause at the time of release you mostly are not aware of the problems.. Regards Werner Am 17.12.2011 21:07 schrieb Agustin Lobo alobolis...@gmail.com: Many thanks Manuel. No hurry for including the patch, once the problem is identified and you even provide a simple way to circumvent it. What is needed is to have users know of these potential problems, ie. through a note of Known Problems included in the release mentioning that the Georeferencer plugin requires users to check that their files do not include an implicit geotransform and use e.g. gdal_translate -co PROFILE=BASELINE -of GTiff Ilerfly125v2.tif Ilerfly125v2-nogeotrans.tif to remove it in case this is actually needed. In other words, once the problem is identified and warned, users can rely on using the software for the rest of cases. The question is thus that, in addition of the excellent developers already involved, we need a team of users and a battery of tests to be regularly performed. Agus 2011/12/17 Manuel Massing m.mass...@warped-space.de: Hi Agustin, The points are correct (therefore the errors etc), but the georeferenced image is shifted. May be the datum is not taken into account when the georeferenced image is created. I did a clean checkout, and could finally reproduce the problem: it stems from the fact that your input file has a geotransform, which flips the yaxis of the local coordinate system and changes the origin. As the geotransform plugin does not handle geotransform info correctly, this results in the shift you have observed. Removing the geotransform (e.g. using gdal_translate -co PROFILE=BASELINE -of GTiff Ilerfly125v2.tif Ilerfly125v2-nogeotrans.tif) should give you a file which the georeferencer can handle correctly (you may have to delete the accompanying .aux file, if gdal uses this to keep the geotransform). I had a local patch in the georeferencer which handles geotransform information, so this is why I couldn't reproduce the problem (talk about a mixture of good and bad luck :-)). I will see what is required to make my local changes ready for submission, so we can avoid such subtle problem with georeferenced/pseudo-georeferenced files in the future. As I already mentioned, due to an important deadline at work, I have little time to dedicate to this atm, so it may take a few day... is there a release in the pipeline? cheers, Manuel ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Georeferencer produces wrong (shifted) result
Il 15/12/2011 21:36, Agustin Lobo ha scritto: myself). I think we should take more steps so that qgis is not released with errors such as this Agreed: we need a more formal approach to release, with a Release Candidate cycle. All the best. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Georeferencer produces wrong (shifted) result
Hi myself). I think we should take more steps so that qgis is not released with errors such as this Agreed: we need a more formal approach to release, with a Release Candidate cycle. All the best. I dont think we need a Release Candidate cycle - From my point that will bring only more confuse into the release cycle.. I guess with RC releases we would probably have some (5?) persons testing the Release Candidate which will in my opinion not lead into more bugs reported or found. People wanting more features are using master anyway .. And people that want to stay on the safe side are using the releases which (and i guess most users are aware of that fact) can always include bugs. If we stick to the release cycle like it is now we would surely have more people using it and detecting more bugs - and with the amount of people it is more likely to get some response. From my point of view the only thing we should do is state clearly somewhere that software can always contain bugs and if there is a bug we should help people report it in any way. I dont think it makes any difference if we release a 1.7.4-rc1 (to rc5?) because people will stick using 1.7.3 as long as 1.7.4 will be released - leading only into more releases not helping us in any way.. Maybe I am wrong but that is what I am getting as response from some users.. kind regards Werner ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Georeferencer produces wrong (shifted) result
Giovanni, 2011/12/15 Giovanni Manghi giovanni.man...@gmail.com: But I'm a bit surprised by the little attention that this problem is raising among developers. A correct georeferencing is a critical issue for a GIS. If this bug is confirmed, users should be warned. probably because if the proper developer (Manuel) cannot replicate the issue it is hard to take any action :) It's not a critique to Manuel, but to the whole community (including myself). I think we should take more steps so that qgis is not released with errors such as this,and if this happens, then users must be warned in the downloading page (a prominent note with important known bugs). qgis is good: warning about important errors will make users be more confident on the package, not less. By the way, using your input data I get also the shift (on both Linux and Windows). This is very useful information, thanks. cheers -- Giovanni -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Georeferencer produces wrong (shifted) result
Hello Agustin, No, the correct one is the one on the left, which is the one made with arcgis. I've made an screenshot with transparency: https://sites.google.com/site/openfiles2/home/errorgeorefARCG_QGIStransp.jp eg?attredirects=0d=1 https://sites.google.com/site/openfiles2/home/errorgeorefARCG_QGIStransp.j pegw?attredirects=0d=1 well, with my setup (ca. qgis 1.7), the output of the georeferencer matches the output from ArcGIS pretty accurately (older revision of QGIS, though - haven't tested with head). See my result, georef output in green: http://www.warped-space.de/georef-vs-arcgis.jpeg The qgis georeferencer output can be found here: http://www.warped-space.de/Ilerfly125v2_modifziert.tif Please upload the output you got, both ArcGIS and georeferencer, so that we can rule out problems on the visualization / on-the-fly reprojection side of things. Also, at this point the exact version of your QGIS/GDAL setup could be relevant. There are some possible sources of error for the discrepancy, e.g. gdal, a faulty entry in the qgis projection database, or user error (well, it happens :-)). cheers, Manuel ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Georeferencer produces wrong (shifted) result
Hi Agus, Cannot download http://www.warped-space.de/Ilerfly125v2_modifziert.tif, I get: Oops! This link appears to be broken. sorry, the correct link is http://www.warped-space.de/Ilerfly125v2_modifiziert.tif The procedure we follow is: 1. Set project to CRS EPSG:23031 2. No On the fly reprojection 3. Start georeferencer and open ilerfly125v2.tif and its points file with the settings displayed thats correct, and I did exactly the same (except for the scale change - might be worth checking out), but couldn't reproduce the shiftr (my results match the output of the arcgis version). I've got a lot on my plate right now, but if I find the time I'll try to look this is a regression in qgis or the georeferencer, as I said I'm still on 1.7 atm. How do the residuals look in the georeferencer? Is there a noticable bias (i.e. do they all point in one direction?) Also, make sure there was no world file influencing the unreferenced file (something like Ilerfly125v2.wld), the georeferencer can't handle that. I also noticed that you used a scale change, does the shift also appear without scale change? cheers, Manuel ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Georeferencer produces wrong (shifted) result
Manuel answers a message I sent to him only. He includes all relevant parts of my message except the link to the arcgis result: https://sites.google.com/site/openfiles2/home/ilerfly125v2geoarcgis.7z?attredirects=0d=1 Manuel, There is no wld file for the input layer The GCP table with errors can be seen here: https://sites.google.com/site/filestemp2/home/GCP.jpeg?attredirects=0d=1 As I'm using gdallib1-1.8.0.2, could this be a gdal problem? Could anybody else using gdallib1-1.8 amd qgis1.7.3 verify (I provided all necessary material)? We have solved the practical issue for this particular image using another software, so we are not in a hurry. But I'm a bit surprised by the little attention that this problem is raising among developers. A correct georeferencing is a critical issue for a GIS. If this bug is confirmed, users should be warned. Agus 2011/12/14 Manuel Massing m.mass...@warped-space.de: Hi Agus, Cannot download http://www.warped-space.de/Ilerfly125v2_modifziert.tif, I get: Oops! This link appears to be broken. sorry, the correct link is http://www.warped-space.de/Ilerfly125v2_modifiziert.tif The procedure we follow is: 1. Set project to CRS EPSG:23031 2. No On the fly reprojection 3. Start georeferencer and open ilerfly125v2.tif and its points file with the settings displayed thats correct, and I did exactly the same (except for the scale change - might be worth checking out), but couldn't reproduce the shiftr (my results match the output of the arcgis version). I've got a lot on my plate right now, but if I find the time I'll try to look this is a regression in qgis or the georeferencer, as I said I'm still on 1.7 atm. How do the residuals look in the georeferencer? Is there a noticable bias (i.e. do they all point in one direction?) Also, make sure there was no world file influencing the unreferenced file (something like Ilerfly125v2.wld), the georeferencer can't handle that. I also noticed that you used a scale change, does the shift also appear without scale change? cheers, Manuel ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Georeferencer produces wrong (shifted) result
Hi Agustin, Please see the screenshot here: https://sites.google.com/site/filestemp2/home/error_georef.jpg?attredirects =0 We've tried polynomia of order 1 and 2 and Helmert, with very similar results. CRS is ED50 UTM31N I've uploaded the input layer and points file to: https://sites.google.com/site/filestemp2/home/Ilerfly125v2.tif?attredirects =0d=1 https://sites.google.com/site/filestemp2/home/Ilerfly125v2.tif.points?attr edirects=0d=1 thanks for your test case. I did a quick test reprojection, but couldn't see a problem with the georeferencer output, i.e. the coordinates generated by the transform fit the destintaion coordinates within a few pixels, putting the max. error somewhere in the ballpark of 1.5m. This relies on the destination coordinates being in ED50 UTM31N. The georeferencer has no support for transforming the destination coordinates, so they need to be specified in the destination CRS. I suspect the discrepancy you are seeing might be a problem with the WGS84-ED50 datum transformation, so it would be helpful if you could provide the ArcGIS output as well. Here you have an screenshot of the comparison to the same image georeferenced with ARCGIS (left) https://sites.google.com/site/filestemp2/home/errorgeorefARCG_QGIS.jpeg?att redirects=0d=1 https://sites.google.com/site/filestemp2/home/errorgeorefARCG_QGIS.jpegw?a ttredirects=0d=1 I guess you meant to say that the right one is from ARCGIS? cheers, Manuel ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Georeferencer produces wrong (shifted) result
Manuel, No, the correct one is the one on the left, which is the one made with arcgis. I've made an screenshot with transparency: https://sites.google.com/site/openfiles2/home/errorgeorefARCG_QGIStransp.jpeg?attredirects=0d=1 https://sites.google.com/site/openfiles2/home/errorgeorefARCG_QGIStransp.jpegw?attredirects=0d=1 You can also note it in the first screenshot: https://sites.google.com/site/filestemp2/home/error_georef.jpg The points are correct (therefore the errors etc), but the georeferenced image is shifted. May be the datum is not taken into account when the georeferenced image is created. Agus 2011/12/13 Manuel Massing m.mass...@warped-space.de: Hi Agustin, Please see the screenshot here: https://sites.google.com/site/filestemp2/home/error_georef.jpg?attredirects =0 We've tried polynomia of order 1 and 2 and Helmert, with very similar results. CRS is ED50 UTM31N I've uploaded the input layer and points file to: https://sites.google.com/site/filestemp2/home/Ilerfly125v2.tif?attredirects =0d=1 https://sites.google.com/site/filestemp2/home/Ilerfly125v2.tif.points?attr edirects=0d=1 thanks for your test case. I did a quick test reprojection, but couldn't see a problem with the georeferencer output, i.e. the coordinates generated by the transform fit the destintaion coordinates within a few pixels, putting the max. error somewhere in the ballpark of 1.5m. This relies on the destination coordinates being in ED50 UTM31N. The georeferencer has no support for transforming the destination coordinates, so they need to be specified in the destination CRS. I suspect the discrepancy you are seeing might be a problem with the WGS84-ED50 datum transformation, so it would be helpful if you could provide the ArcGIS output as well. Here you have an screenshot of the comparison to the same image georeferenced with ARCGIS (left) https://sites.google.com/site/filestemp2/home/errorgeorefARCG_QGIS.jpeg?att redirects=0d=1 https://sites.google.com/site/filestemp2/home/errorgeorefARCG_QGIS.jpegw?a ttredirects=0d=1 I guess you meant to say that the right one is from ARCGIS? cheers, Manuel ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
