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
[email protected] http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
