[Qgis-developer] Datum transformations

[Marco Hugentobler]

Hi Martin

 >if some code in QGIS creates coordinate transform
 >without using transform provided by map renderer, it will be created
 >without the chosen datum transform and will therefore provide
 >incorrect results

There is a lot of code and plugins that rely on the assumption that a 
coordinate transformation is fully defined by source crs and destination 
crs. I agree it is not an ideal situation, however that assumption is 
simply not correct  and it probably takes some time until all places are 
changed. I remember having changed that for QgsVectorFileWriter, but 
other places (e.g. measuring tool) still behaves not correct.

>I guess there is still a question what to do in cases when there are
>more layers with the same CRS but with different datum transforms - I
>am not sure how well the current implementation handles that case (if
there is a datum transform defined in options, it will be used for all
layers with given CRS)


This is my main concern regarding caching of datum transformation. It is 
very important to have the possibility to control the datum 
transformation for each layer individually. E.g. it is quite common to 
load a layer twice with different datum transformations to see the 
difference. This was actually my main visual test during implementation, 
so I'm quite sure it works in 2.2 (or at least it was when I tested that 
last time). In case a user defines  a default transformation, he accepts 
that it will be silently used for all layers (and there is still the 
possibility to delete that in options).

>- GUI: have a tab in project properties where non-default datum
>transforms would be managed - instead of requiring the user to select
>the datum transform immediately when the layer was added (and without
>being able to change the decision later)


I don't have a strong opinion if it should be in project properties or 
if the user should be asked immediately. The immediate selection has 
been implemented following the behaviour of a commercial GIS. However, 
the possibility to change it later easily does also sound good to me.

Btw., congratulations to the merge of the multithreading branch!

Regards,
Marco


On 24.02.2014 06:03, Martin Dobias wrote:
> Hi (Marco)
>
> I have some suggestions for the implementation of datum transforms in
> QGIS and I would like to hear your opinion about them.
>
> In the 2.2 release, as far as I understand the logic is implemented like this:
> - map renderer emits a signal asking for datum transform choice
> - map canvas catches the signal and provides either the default
> (defined in options) or asks the user in a dialog - and sends this
> information back to map renderer
> - map renderer stores the information about datum transforms and does
> loading/saving in project file
> - map renderer provides access to coordinate transforms (with correct
> datum transform info)
>
> The main issue I see here is the fact that in case of non-default
> datum transforms - if some code in QGIS creates coordinate transform
> without using transform provided by map renderer, it will be created
> without the chosen datum transform and will therefore provide
> incorrect results. This can lead to subtle bugs (for example,
> QgsVectorFileWriter will not use the defined datum transforms, causing
> offsets in reprojected data). Changing all the possible places where
> coordinate transform may be used to call
> QgsMapRenderer::transformation() seems impractical.
>
> What do you think about:
> - using QgsCoordinateTransformCache internally by
> QgsCoordinateTransform anytime a new transform should be instantiated
> - keeping the datum transform information in a helper class
> (loaded/saved by project) and using it directly by
> QgsCoordinateTransform - so any QGIS code will use the correct datum
> transform
> - GUI: have a tab in project properties where non-default datum
> transforms would be managed - instead of requiring the user to select
> the datum transform immediately when the layer was added (and without
> being able to change the decision later)
>
> Currently the datum transforms do not work at all in master after the
> merge of MTR because the QgsMapRenderer class is not used for
> rendering anymore. Before trying to do anything in that area I would
> like to hear your input.
>
> I guess there is still a question what to do in cases when there are
> more layers with the same CRS but with different datum transforms - I
> am not sure how well the current implementation handles that case (if
> there is a datum transform defined in options, it will be used for all
> layers with given CRS) and how much we need such functionality.
>
> Regards
> Martin


-- 
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee