Bug report #722
LCC projection not recognized (EPSG 3358)
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Low | ||
| Assignee: |  Aaron Racicot - | ||
| Category: | Projection Support | ||
| Affected QGIS version: | Regression?: | No | |
| Operating System: | Mandriva | Easy fix?: | No |
| Pull Request or Patch supplied: | Resolution: | fixed | |
| Crashes QGIS or corrupts data: | Copied to github as #: | 10781 |
Description
Hi,
it appears that QGIS fails to recognize NAD83 / North Carolina LCC:
Warning: [[QgsSpatialRefSys]]::getRecord failed : select * from tbl_srs where parameters='+proj=lcc +lat_1=34.33333333333334 +lat_2=36.16666666666666 +lat_0=33.75 +lon_0=-79 +x_0=609601.22 +y_0=0 +ellps=GRS80 +datum=NAD83 +units=m +no_defs' Warning: [[QgsSpatialRefSys]]::findMatchingProj -------> no match found in user db Warning: QPainter::begin: Painter already active Warning: QPainter::begin: Painter already active Warning: [[QgsSpatialRefSys]]::createFromSrsId failed : select srs_id,description,projection_acronym,ellipsoid_acronym,parameters,srid,epsg,is_geo from tbl_srs where srs_id='-1223020544'
The reason will be that the EPSG definition in PROJ4 is this:
# NAD83(HARN) / North Carolina <3358> +proj=lcc +lat_1=36.16666666666666 +lat_2=34.33333333333334 +lat_0=33.75 +lon_0=-79 +x_0=609601.22 +y_0=0 +ellps=GRS80 +units=m +no_defs <>
Note that the values of lat_1 and lat_2 are reverted. I was told by Frank W. that this is legal (to my shame I already submitted a bug report to EPSG). It would be good if QGIS accepted the reverted lat_1 and lat_2, too.
Best,
Markus
bug722fix.diff 
- Patch for bug 722 - bug722fix.diff
(4.02 KB)
bug722fix.tar.gz - Test files for bug #722 - bug722fix.tar.gz (79.2 KB)
History
#1
Updated by Aaron Racicot - over 16 years ago
- Status changed from Open to In Progress
#2
Updated by Aaron Racicot - over 16 years ago
The patch labeled bug722fix.patch is attached to this ticket and addresses the searching for matching proj4 strings with swapped lat_1 and lat_2 strings. The basic idea is that after getting a failure when checking our base proj4 string against the srs database we can try to swap lat_1 and lat_2 (if they exist) and try again. If we succeed we grab the srsid for the matching projection and continue. If we fail we continue on the same path of testing for parts of the proj4 string as was previously done.
I have also attached a sample dataset that can be used to test this fix. It is a simple 4 polygon shapefile. There are two copies... one in EPSG 32149 and the other in EPSG 32149 with the lat_1 and lat_2 parameter values swapped. Here is the output from QGIS (with debug on):
++++++++++++++++++++++++++++++++++
WHEN LOADING co_32149.shp::
Debug: /usr/local/src/qgis/qgis_svn/src/providers/ogr/qgsogrprovider.cpp: 1385:
(getSRS) Data source file name is : /home/aaronr/work/tmp/qgisbug722/co_32149.shp
Debug: /usr/local/src/qgis/qgis_svn/src/core/qgsspatialrefsys.cpp: 733:
(getRecord) QgsSpatialRefSys::getRecord retrieved: select * from tbl_srs where
parameters='+proj=lcc +lat_1=47.33333333333334 +lat_2=45.83333333333334
+lat_0=45.33333333333334 +lon_0=-120.5 +x_0=500000 +y_0=0 +ellps=GRS80 +datum=NAD83
+units=m +no_defs'
++++++++++++++++++++++++++++++++++
WHEN LOADING co_32149_Swap.shp::
Debug: /usr/local/src/qgis/qgis_svn/src/providers/ogr/qgsogrprovider.cpp: 1385:
(getSRS) Data source file name is : /home/aaronr/work/tmp/qgisbug722/co_32149_Swap.shp
Warning: QgsSpatialRefSys::getRecord failed : select * from tbl_srs where
parameters='+proj=lcc +lat_1=45.83333333333334 +lat_2=47.33333333333334
+lat_0=45.33333333333334 +lon_0=-120.5 +x_0=500000 +y_0=0 +ellps=GRS80 +datum=NAD83
+units=m +no_defs'
Debug: /usr/local/src/qgis/qgis_svn/src/core/qgsspatialrefsys.cpp: 608:
(createFromProj4) QgsSpatialRefSys::createFromProj4 - trying proj4string match with
swapped lat_1,lat_2
Debug: /usr/local/src/qgis/qgis_svn/src/core/qgsspatialrefsys.cpp: 733: (getRecord)
QgsSpatialRefSys::getRecord retrieved: select * from tbl_srs where
parameters='+proj=lcc +lat_1=47.33333333333334 +lat_2=45.83333333333334
+lat_0=45.33333333333334 +lon_0=-120.5 +x_0=500000 +y_0=0 +ellps=GRS80 +datum=NAD83
+units=m +no_defs'
++++++++++++++++++++++++++++++++++
So you can see that the original file was found on the first try, while the swapped parameter file was found only after swapping the lat_1 and lat_2 in the search string.
While this fixes the initial problem reported in this bug, there still is an issue in QGIS where as a single character difference in the proj4 definition for a file will cause the string search to fail. This can happen for any number of reasons including rounding errors etc.
#3
Updated by Tim Sutton over 16 years ago
- Resolution set to fixed
- Status changed from In Progress to Closed
Thanks Aaron - your patch is committed as 0bc0ed41 (SVN r7462)
Tim
#4 Updated by Anonymous over 14 years ago
Milestone Version 0.9.1 deleted