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.bla...@gmail.com> wrote:
On Thu, Jul 4, 2013 at 8:59 AM, Jürgen E. <j...@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
Qgis-developer mailing list
Qgis-developer@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.hugentob...@sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee
_______________________________________________
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
