[QGIS-trac] Re: [Quantum GIS] #1875: A few problems with crs definitions with TOWGS parameters

[Quantum GIS]

#1875: A few problems with crs definitions with TOWGS parameters
--------------------------------------------------------------+-------------
        Reporter:  lutra                                      |         Owner:  homann       
            Type:  bug                                        |        Status:  closed       
        Priority:  critical: causes crash or data corruption  |     Milestone:  Version 1.2.0
       Component:  Projection Support                         |       Version:  HEAD         
      Resolution:  fixed                                      |      Keywords:               
Platform_version:                                             |      Platform:  All          
        Must_fix:  No                                         |   Status_info:  0            
--------------------------------------------------------------+-------------
Comment (by hamish):

 Replying to [comment:41 homann]:
 > So, it appears that the WKT your v.out.ogr module wrote
 > isn't translatable by OGR itself, or rather it does not
 > represent EPSG 27200.

 The export module is not trying to represent EPSG code X (actually by that
 point it has already forgotten what the seed EPSG code was). It's trying
 to export a series of non-overlapping coefficients and labels which
 describe a CRS as best it can. Frank's scripts which create the
 /usr/share/proj/espg file only approximate what is really in the EPSG
 database; some codes are not representable by +proj4 syntax at all (eg
 multiple datums defined for a single code). In the past there have been
 library function changes which inadvertently changed the proj4 epsg file's
 floating point low signif. digit end rounding, causing e.g. msieczka's
 exact-match problems in and about the time of #1079.

 > So why do you belivee that QGIS is wrong? The suppplied WKT
 > is not the same as what OGR thinKS EPSG 27200 should be.

 QGIS is passed WKT which says "DATUM["New_Zealand_Geodetic_Datum_1949","
 and it fails to convert that to the proj term +datum=nzgd49. That name is
 the same as `"proj -ld"` gives for the datum name, it's the Well-Known
 non-ESRI variant. The CRS import code should be flexible enough to figure
 that out and not depend on strcmp() of all components.

 (my hunch is that "international" vs "International 1924" ellipsoid
 definition is the culprit in this case)

 Is it a fault in the QGIS or OGR codebase? I've no idea. Probably a mix of
 both or a misassumption of one by the other.

 It doesn't matter if the program recognizes that the terms of EPSG 27200
 are highly similar to the WKT given, just as long as the +proj4 terms get
 populated correctly.

 http://spatialreference.org/ref/epsg/27200/

 And FWIW, it's not EPSG-KT, it's WKT. And there are ~5 different flavors
 of WKT depending on the vendor, so insisting that it matches the current
 OGR-generated version precisely to work properly ain't going to help when
 someone shows up with some data from a popular non-OSGeo family GIS. WKT
 is a very sloppy human-readable definition and always will be. It is much
 harder to program, but a robust fuzzy-logic system needs to be flexible
 and smart when handed that slop.


 thanks and best regards,
 Hamish

-- 
Ticket URL: <https://trac.osgeo.org/qgis/ticket/1875#comment:42>
Quantum GIS <http://qgis.org>
Quantum GIS is an Open Source GIS viewer/editor supporting OGR, PostGIS, and GRASS formats