[Qgis-developer] Datum transformations

[Martin Dobias]

Hi Marco

On Mon, Feb 24, 2014 at 4:45 PM, Marco Hugentobler
<marco.hugentobler at sourcepole.ch> 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