[Qgis-developer] SRS DB maintenance

[Radim Blazek]

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