[Qgis-developer] Datum transformations

[Marco Hugentobler]

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
> <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


-- 
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