[QGIS-Developer] QGIS Georeferencer improvements

[Nyall Dawson]

On Sat, 14 Mar 2020 at 01:13, Martin Dobias <wonder.sk at gmail.com> wrote:

>
> 1. Georeferencer opens in a new window. In order to see the main map
> canvas and the georeferenced layer side by side, it is necessary to do
> some resizing of windows which is inconvenient. It would be maybe more
> practical to have the georeferenced image in a dock widget in the main
> window - and all georeferencer related map tools included in the main
> QGIS window as well. (Or maybe the other way around - to keep
> georeferencer as a separate window, but allow the main map canvas to
> be embedded in it?)

I would personally prefer the second option. I think a significant
amount of users doing regular georeferencing would have dual screen
setups (or large screens) and would appreciate having the a larger
georeferencer window then a dock would allow.

> 2. Georeferencer is a plugin. Its core/gui functionality cannot be
> reused elsewhere. It would be useful to have some Processing
> algorithms to load/save GCPs, to extract GCPs to raster images, to
> save GCPs to raster images and to warp imagery according to GCPs (and
> chosen transformation method).

Totally agree! (Also -- add "warp vectors according to GCPs" here --
gdal exposes all the required functionality through the public c api,
so it's nearly a freebie!)

> 4. It uses a combination of GDAL-based transformation methods
> (Polynomial of 1st/2nd/3rd order, thin plate spline) and some of its
> own (Helmert, Projective), for which it also requires GSL library as a
> dependency. In my opinion, QGIS georeferencer should leave all the
> math to GDAL which does a great job there. Moreover, I have some
> doubts about the methods that do not come from GDAL: the “Helmert”
> method is simply 2D affine transform (offset+scale+angle), while true
> Helmert transformation is 3D transformation with 7 parameters. Do we
> need it if GDAL’s 1st order polynomial transformation should do just
> that? And the “Projective” method which is a bit of a mystery to me.
> First of all, I am not sure in what situation it is useful and the
> documentation only says it is “a linear rotation and translation of
> coordinates” - which is a bit vague. It looks like a subset of RPC
> method supported by GDAL (although GDAL does not have estimation of
> RPC coefficients). Overall I would be for removal of these methods and
> stick to what GDAL offers.

No strong opinions here from a user perspective. I always just choose
"projective" in this list, for absolutely no scientific reasons.
Someone years and years ago told me it was best and I never bothered
to look into it myself :P

>From a QGIS dev perspective +1 to just relying entirely on gdal here.

> I would be keen to hear what you think, if you agree/disagree with the
> above or have some ideas how to improve things here.

Sounds great! Can I make some more suggestions:

1. Add vector georeferencing capabilities. This really isn't as much
work as it sounds, as
    - we already use a canvas to show the layer being referenced, so
it would be trivial to show ungeoreferenced vectors in this window
    - gdal exposes similar api for warping vectors based on gcps as it
does for rasters -- there's no heavy lifting required on the qgis side
So adding vector support is just a matter of considering it in the
code + a few extra choices in the UI. And there's a very strong need
for vector georeferencing (especially in the engineering world. True
story: I once had to georeference a highway design document which was
made in visio using a screenshot of google maps in the backend).

2. It should be possible to move the actual georeferencing operation
to a task. Warping some large images can be slooooow, so it's painful
that it currently blocks QGIS. I did some in-depth research
surrounding this a couple of years ago and there was nothing blocking
it. At the time it would have been just a matter of shuffling around a
bunch of the georeferencing code, but it sounds like you're planning
to do that anyway!

3. The georeferencer has serious UX issues surrounding CRS selection.
At the moment, you open a non-georeferenced image in it and you're
asked immediately for a CRS. That choice is completely redundant and
confusing! Also, it's really easy to make a serious mess of
georeferencing. If you pick points from the canvas the points are
stored in the gcp list in the canvas crs. Then when you perform the
actual reference if you pick a different destination crs for the image
you get messed up results. The two should be totally disconnected --
you should be able to pick points from the canvas and then later save
the result in a different crs without issue (the gcps should be
transformed automatically to the desired destination crs)

Exciting stuff!
Nyall

>
> Regards
> Martin
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer