Feature request #2890
Georeference's plugin can work with changes of projections
|Pull Request or Patch supplied:||No||Resolution:|
The patch allows Georeference´s plugin work changes of projections.
1) The display of GCP's in QGis mapcanvas with
projection changes in QGis (property of project - Coordinate Reference System)
2) The reference coordinates (Map) in GCP table change when new setting of EPSG in plugin.
3) Show EPSG (reference coordinates) in table of GCP and dialog input coordinate (EPSG of Qgis mapcanvas)
#2 Updated by mmassing - almost 7 years ago
- Status changed from Open to In Progress
thank you for your contribution. I must confess I haven't fully understood the patch
description, so can't really comment on it right now, but I will test it out and give you
For the future, it would be great if you could submit your changes as patches (i.e., the output
of "svn diff") instead of submitting the whole source files. This makes it a lot easier to
review and apply changes.
See http://www.qgis.org/wiki/Developers_Manual#Submitting_Patches for details on how to
#5 Updated by Luiz Motta almost 7 years ago
Sorry! The georeferencer_paths_lmotta.2.zip is not valid ( have same zips of georeferencer_paths_lmotta.zip add in 07/21/2010).
Patch and diff files updated.
The patch fixed the bug about raster layer of Plugin Georeferencer when the user open the new Qgis project. At the moment, the raster layer is loaded again after new project is open.
#9 Updated by mmassing - almost 7 years ago
I am not including the reprojection code at the moment, because it has some issues which I'd like to resolve first. The main problem is that a user can easily run into cases which
result in destructive transformation of GCP coordinates or which work in a counter-intuitive
fashion. I think with the current implementation it would be best to only let the user reproject
GCPs explicitly (e.g. by selecting it as a function from the menu, or by enabling it
explicitly), and not trying to guess from/to which SRS to reproject to avoid any confusion or
1) Does only work with EPSG projections (i.e. does not work with user-defined projections, or +proj4 based projections without EPSG code). Entering a non-EPSG projeciton trips up the automatic reprojection completely.
2) Automatic reprojection may not be desired for a variety of reasons, e.g. because reprojection
may be associated with a loss of precision.
3) The transform may fail (e.g. because some coordinates can not be represented in the new
coordinate system), resulting in information loss - this can happen as the result of a seemingly
unrelated user-action (e.g., opening a new project, or changing the projects transformation settings in QGis)
4) The reprojection makes assumptions about the destination SRS which may not be valid.
In particular, it may become impossible to even open a file if the projection (as set in the
gis project settings) results in an invalid transformation of the GCPs.
These problems could maybe be addressed cleanly by storing all GCP destination coordinates in a
fixed geographic reference frame (e.g. WGS84), and deriving the reprojected coordinates only
when needed (e.g. when displaying them to the user, or when fitting the parametrized
transform). This would avoid SRS ambiguities, curb precision loss and make it possible to recover from failed reprojection attempts.
#10 Updated by Luiz Motta almost 7 years ago
Thanks for commit my contributions.
About the reproject. My point of view it was to ensure the projection for georeference is the same projection in QGis canvas, because need had explicit projection to harvest of GCP, in this case, it is same QGis Canvas.