[QGIS-trac] Re: [Quantum GIS] #1079: on the fly projections do not work

Quantum GIS qgis at qgis.org
Tue May 13 08:36:41 EDT 2008


#1079: on the fly projections do not work
--------------------------------------------------------------+-------------
        Reporter:  pcav                                       |         Owner:  mhugent      
            Type:  defect                                     |        Status:  new          
        Priority:  critical: causes crash or data corruption  |     Milestone:  Version 0.9.2
       Component:  Projection Support                         |       Version:  HEAD         
      Resolution:                                             |      Keywords:               
Platform_version:                                             |      Platform:  All          
        Must_fix:  Yes                                        |   Status_info:  0            
--------------------------------------------------------------+-------------
Changes (by msieczka):

  * priority:  major: does not work as expected => critical: causes crash
               or data corruption
  * platform:  Debian => All
 * cc: msieczka (added)
  * milestone:  => Version 0.9.2

Comment:

 AFAIK, QGIS fails to recognize only SRSs which contain an *explicit k
 parameter* in the SRS proj4 string (which are several hundred SRSs
 anyway). It does recognize other properly though. The nature of the
 problem depends on the *particular* coordinate system *and GDAL version*,
 and has it's background in the fact that QGIS uses proj4 faromat-based,
 string-wise SRS matching.

 Example:

 EPSG:2180 has a following proj4 representation in QGIS srs.db:

 {{{
 +proj=tmerc +lat_0=0 +lon_0=19 +k=0.999300 +x_0=500000 +y_0=-5300000
 +ellps=GRS80 +units=m +no_defs
 }}}

 Against GDAL 1.4.4 QGIS fails to recognize this SRS because GDAL 1.4.4
 inteprets EPSG:2180 as:

 {{{
 +proj=tmerc +lat_0=0 +lon_0=19 +k=0.9993 +x_0=500000 +y_0=-5300000
 +ellps=GRS80 +units=m +no_defs
 }}}

 Note the difference in k above - 0.999300 against 0.9993 is the cause of
 string-wise matching failure. The reason of this problem is a change in
 GDAL http://trac.osgeo.org/gdal/changeset/12625.


 Against GDAL > 1.4.4 QGIS fails to recognize this SRS because these GDAL
 versions intepret EPSG:2180 as:

 {{{
 +proj=tmerc +lat_0=0 +lon_0=19 +k=0.9993000000000001 +x_0=500000
 +y_0=-5300000 +ellps=GRS80 +units=m +no_defs
 }}}

 Again, k differ in both cases. This one is due to a bug in GDAL
 https://trac.osgeo.org/gdal/ticket/2036. It is fixed in GDAL 1.6 trunk but
 the fix caused side-effects, which have to be taken care of before the fix
 can be backported to stable 1.5 branch.

 Other SRS which do not conatin an explicit k parameter, eg. EPSG:32633,
 which in proj4 representaion is:

 {{{
 +proj=utm +zone=33 +ellps=WGS84 +datum=WGS84 +units=m +no_defs
 }}}

 do not pose problems.

 Back to the point - if QGIS fails to recognize the SRS of the added layer,
 by default it assignes it:

 {{{
 +proj=longlat +ellps=WGS84 +datum=WGS84
 }}}

 Now, when one tries to reproject such layer on the fly, he might come to
 wrong conclussion that the functionality is broken. However, the real
 culprit is that the *layer's source SRS is wrong*, so the reprojection
 cannot work properly. Can you Leonardo and Paolo please verify if this is
 the case for you - that for Paolo the reprojection seems broken and for
 Leonardo it's OK?

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


More information about the QGIS-trac mailing list