Hi Martin
To me it sounds like an acceptable limitation to support just one
particular datum transformation at a time for one project.
I still think this limitation is not acceptable. Datum transformation is
a very approximate thing. Some transformation are well suited for
particular areas, but not for others. So you can easily have several
layers using different transforms in one project.
And don't forget that QgsCoordinateTransformCache is used by one server
instance. We have hundreds of projects on qgiscloud. We cannot force all
of them to use the same datum transformations.
Regards,
Marco
On 25.02.2014 11:46, Martin Dobias wrote:
Hi Marco
On Mon, Feb 24, 2014 at 4:45 PM, Marco Hugentobler
<[email protected]> wrote:
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 do not think that changing the individual pieces of code to
explicitly support the datum transforms is the way to go. It would be
very hard to make sure that all occurrences of datum transforms behave
properly just in QGIS itself, not speaking about python plugins.
Handling of datum transforms is a more complicated topic that not
everybody understands, so not having consistent behavior all across
QGIS will lead to an endless stream of problems for users who would
try to take advantage of datum transforms. I believe we need a
systematic approach where the the datum transforms will just work
without extra effort from the developer - this would maybe limit some
functionality (just one possible datum transform for a pair of
source-destination CRS), but it will _always_ give correct results.
For example, the saving of vector layers (QgsVectorFileWriter) has
been enhanced to support datum transforms, but there are dozens of
occurrences in QGIS tree which do not use it and therefore they may
end up writing incorrect results. And that is just one utility
class...
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).
To me it sounds like an acceptable limitation to support just one
particular datum transformation at a time for one project. It may
bring some inconvenience for some users, but it seems that it is
better to clearly know the limitations rather than quietly doing wrong
transformations. The users can still explicitly reproject the data to
the destination CRS to overcome such limitation.
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
