[Qgis-developer] SRS DB maintenance

[Marco Hugentobler]

>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. QgsCoordinateTransform would then adjust the proj-strings 
of source and dest CRS on the fly.

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