[Qgis-developer] SRS DB maintenance

[Marco Hugentobler]

>Where do you want to let user select the transformation? In my opinion
>it should be possible everywhere where CRS may be selected (including
>OWS dialogs). That means not to have one global transformation set for
>user or project because it may happen that it is necessary to work
>with data with different transformations in a single project.

Good point. Probably the user should be asked if setting/changing CRS of 
a layer or if user changes the map CRS (in that case he is asked for all 
layers). It might be a bit of a useability challenge to make this user 
friendly (especially for users who don't bother about transformations).

>Is it possible to do it without API break?

I hope it is possible to enhance QgsCoordinateTransform with additional 
methods (reading transformations from sqlite, reading/writing to project 
file, etc...). My guess is that it is possible without break.

Regards,
Marco



On 04.07.2013 12:27, Radim Blazek wrote:
> On Thu, Jul 4, 2013 at 11:56 AM, Marco Hugentobler
> <marco.hugentobler at sourcepole.ch> wrote:
>>> While the relation between CRS and transformation in EPSG database is
>>> (naturally) one-to-many, QGIS oversimplified the relation to
>>> one-to-one
>>> We should probably
>>> separate CRS from towgs84 and allow users to choose from multiple
>>> towgs84 for CRS.
>> We have a similar problem here with multiple transformations between two
>> coordinate systems (ntv2 based transformation more accurate in that case).
>> So I was also thinking about enhancing the coordinate transformation class
>> to store transformations in a table (import from epsg transformation info)
>> and let the user select the transformation in case several exist.
> Where do you want to let user select the transformation? In my opinion
> it should be possible everywhere where CRS may be selected (including
> OWS dialogs). That means not to have one global transformation set for
> user or project because it may happen that it is necessary to work
> with data with different transformations in a single project.
>
>> QgsCoordinateTransform would then adjust the proj-strings of source and dest
>> CRS on the fly.
> Is it possible to do it without API break?
>
> Radim
>
>> What do you think about such a solution? It looks like I have the
>> possibility to work quite soon on such an enhancement.
>>
>> Regards,
>> Marco
>>
>>
>>
>>
>>
>> On 04.07.2013 11:30, Radim Blazek wrote:
>>> Note. The database from epsg.org does contain the correct
>>> transformations (towgs84) 4836 (SK) and 5239 (CZ), the problem is that
>>> each one is for a different territory but the same CRS. While the
>>> relation between CRS and transformation in EPSG database is
>>> (naturally) one-to-many, QGIS oversimplified the relation to
>>> one-to-one. So all the evil comes from QGIS itself. We should probably
>>> separate CRS from towgs84 and allow users to choose from multiple
>>> towgs84 for CRS.
>>>
>>> Radim
>>>
>>> On Thu, Jul 4, 2013 at 11:00 AM, Radim Blazek <radim.blazek at gmail.com>
>>> wrote:
>>>> On Thu, Jul 4, 2013 at 8:59 AM, Jürgen E. <jef at norbit.de> wrote:
>>>>> 7805af3cf introduces a noupdate field in tbl_srs, that is set to 1 for
>>>>> the
>>>>> mentioned CRSes.  And crssync doesn't update or delete records marked
>>>>> like
>>>>> that.
>>>> Great, thanks.
>>>>
>>>>> But that flag should probably tracked somehow and set to 0 eventually,
>>>>> when the CRSes get corrected in/introduced to geotiff/GDAL/proj.4.
>>>> It seems that GDAL is occasionally synced with EPSG from libgeotif
>>>> [1], no additional overrides. In [2] is described EPSG in libgeotif.
>>>> They keep overrides separate in gcs.override.csv and pcs.override.csv,
>>>> it is not clear to me if gcs/pcs.override.csv are used somehow by
>>>> crssync or not.
>>>>
>>>> If I got it,  If we want to get correct towgs84 params to srs.db in a
>>>> clean way, they must be added to libgeotif gcs/pcs.override.csv and
>>>> crssync must use them.
>>>>
>>>> BTW, we have a problem [2]:
>>>>
>>>> "Note that we deliberately keep alterations separate from the EPSG
>>>> definitions
>>>> in gcs.csv and pcs.csv to avoid violating the EPSG distribution license
>>>> which requires that the definitions be distributed in unaltered form."
>>>>
>>>> Radim
>>>>
>>>> [1] http://trac.osgeo.org/gdal/log/trunk/gdal/data/pcs.csv
>>>> [2] http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/README
>>>>
>>>>> Jürgen
>>>>>
>>>>> [1] http://en.wikipedia.org/wiki/DWIM
>>>>>
>>>>> --
>>>>> Jürgen E. Fischer         norBIT GmbH               Tel.
>>>>> +49-4931-918175-31
>>>>> Dipl.-Inf. (FH)           Rheinstraße 13            Fax.
>>>>> +49-4931-918175-50
>>>>> Software Engineer         D-26506 Norden
>>>>> http://www.norbit.de
>>>>> committ(ed|ing) to QGIS                                IRC: jef on
>>>>> FreeNode
>>>>>
>>>>> --
>>>>> norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme
>>>>> mbH
>>>>> Rheinstrasse 13, 26506 Norden
>>>>> GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502
>>>>>
>>>>> _______________________________________________
>>>>> Qgis-developer mailing list
>>>>> Qgis-developer at lists.osgeo.org
>>>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> _______________________________________________
>>> Qgis-developer mailing list
>>> Qgis-developer at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>> --
>> 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
>>
>>
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer


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