[Backport release-3_22] Fix lots of georeferencer issues #47276
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
destination coordinates, and whether they are in pixels/map coordinates And make some TODO notes flagging errors identified along the way
… issues when a second raster is loaded into the georeferencer
…ults in incorrect placement of source points
…y complicates the code
…points must ALWAYS be in source layer coordinates
raster file name for these and not the output raster file name The GCPs relate specifically to the ORIGINAL image, not the warped output exported after georeferencing. If we use the output file name for the .points file then when THIS georeferenced output is loaded into the georeferencer we get misleading location of source GCP points, as the pixel coordinates are from the ORIGINAL image, not the warped one.
from class which stores graphical item representing point
This is too fragile, there's too many different situations which should lead us to invalidate the cached point which are not being caught.
points instead of always using source pixel row/columns The "always use pixels" approach does not work well when a source image already has some georeferencing information attached. Also add tests for this, and fix loading of "enabled" status for points when loading points from a file
enabled And partially fix this functionality when using an already georeferenced image (not fully)
(cherry picked from commit 23402c8)
(cherry picked from commit d76fe79)
(cherry picked from commit 977585c)
points don't move on canvas when edited in list (cherry picked from commit ca2dbef)
points in table are always updated to reflect actual target CRS whenever it is changed (cherry picked from commit 15d7c8a)
(cherry picked from commit 610a0a6)
(cherry picked from commit a2bb366)
georeferenced, assume the source points are in the raster's IF there's no explicit crs information in the .points file (cherry picked from commit 8a12a0b)
(cherry picked from commit feaa954)
(cherry picked from commit a39ed7b)
set CRS of destination to match the georeference target CRS (cherry picked from commit 90c1325)
(cherry picked from commit 93564e0)
Helps clarify for users exactly what CRS these destination coordinates are in (cherry picked from commit 622c120)
(cherry picked from commit 27db775)
(cherry picked from commit 4877003)
(cherry picked from commit 4e035e6)
|
Also includes #47279 |
nirvn
approved these changes
Feb 14, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport #47141
Authored by: @nyalldawson