Bug report #1487
QGIS fails to recognise Shapefile projection
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Low | ||
| Assignee: |  nobody - | ||
| Category: | Projection Support | ||
| Affected QGIS version: | Regression?: | No | |
| Operating System: | Gentoo | Easy fix?: | No |
| Pull Request or Patch supplied: | Resolution: | fixed | |
| Crashes QGIS or corrupts data: | Copied to github as #: | 11547 |
Description
When loading shapefile with defined projection into QGIS 1.0.0 pr2, it shows up as layer without coordinate information (assigned default one). ogrinfo reports projection info just fine. Shapefile is created with Phyton + OGR and as SRS is used EPSG:3059
ogrinfo -ro -so bbox_3059.shp bbox_3059
INFO: Open of @bbox_3059.shp'
using driver @ESRI Shapefile' successful.
Layer name: bbox_3059
Geometry: Polygon
Feature Count: 240
Extent: (28.110982, 56.323566) - (1050169.240520, 524386.627352)
Layer SRS WKT:
PROJCS["LKS92 / Latvia TM",
GEOGCS["LKS92",
DATUM["Latvia_1992",
SPHEROID[[GRS_1980]],
PRIMEM[[Greenwich]],
UNIT[[Degree]],
PROJECTION[[Transverse_Mercator]],
PARAMETER[[latitude_of_origin]],
PARAMETER[[central_meridian]],
PARAMETER[[scale_factor]],
PARAMETER[[false_easting]],
PARAMETER[[false_northing]],
UNIT[[Meter]]
FID: Real (11.0)
History
#1
Updated by Frank Warmerdam - almost 16 years ago
I have confirmed on my machine that the SRS does not appear in the vector layer metadata properties dialog. The debug output suggests much effort is made matching it and failing.
#2
Updated by Frank Warmerdam - almost 16 years ago
No match is found because the EPSG:3059 entry in the srs.db includes a towgs84 parameter lacking in the ESRI .prj file.
I really have no idea why a coordinate system needs to exist in srs.db to be considered valid. What's with that?
#3
Updated by Frank Warmerdam - almost 16 years ago
Tim,
It was suggested you are a QGIS CRS guru of sorts, and I have taken the liberty of adding you to the cc list. Perhaps we could discuss the matter in IRC at some point - particularly why the matching is necessary.
#4
Updated by Martin Dobias almost 16 years ago
- Resolution set to fixed
- Status changed from Open to Closed
This has been fixed in .
Frank - to explain the inner working of the CRS recognition: given a proj4 string, qgis tries to match it to database. Reason for this is to find out EPSG id, srid and name of the projection. If it fails doing exact match, it goes through the database entries and compares the two projections using OSRIsSame (resp. OSRIsSameGeogCS). If this search fails too, it creates CRS just using the proj4 string (projection name and ids are not resolved). If everything fails, it just uses wgs84 or some other default CRS.
This might not be the best logic (personally I'm not really confident with roboustness of OSRIsSame), so any ideas for improvement are mostly welcome.
Martin
#5
Updated by hamish - over 15 years ago
Hi,
a sort of related question about this fix:
if you have just started the program and this is the first data layer you have loaded AND you have not already set the CRS with the "P" setup, will it automatically set the uninitialized CRS to match the CRS of the first layer, or do you still have to manually adjust the project's CRS to match the layers? it would be awesome if that could happen automatically. (maybe it now does?)
thanks,
Hamish
#6
Updated by marisn - over 15 years ago
- Status changed from Closed to Feedback
- Resolution deleted (
fixed)
Still fails with QGIS 1.2.0 (da17b5de (SVN r11430)). Related question - why QGIS SRS definition differs from one created by OGR?
Here's console output:
Critical: [[QgsCoordinateReferenceSystem]]::createFromWkt -- theWkt is uninitialised, operation failed Critical: [[QgsCoordinateReferenceSystem]]::createFromWkt -- theWkt is uninitialised, operation failed Warning: QMetaObject::connectSlotsByName: No matching signal for on_btnHelp_clicked() Warning: [[QgsCoordinateReferenceSystem]]::getRecord failed : select * from tbl_srs where parameters='+proj=tmerc +lat_0=0 +lon_0=24 +k=0.9996 +x_0=500000 +y_0=-6000000 +ellps=GRS80 +units=m +no_defs' Warning: [[QgsCoordinateReferenceSystem]]::findMatchingProj -------> no match found in srs.db, trying user db now! Warning: [[QgsCoordinateReferenceSystem]]::findMatchingProj -------> no match found in user db Warning: QMetaObject::connectSlotsByName: No matching signal for on_btnClose_clicked() Warning: QMetaObject::connectSlotsByName: No matching signal for on_btnHelp_clicked() Warning: [[QgsCoordinateReferenceSystem]]::getRecord failed : select * from tbl_srs where parameters='+proj=tmerc +lat_0=0 +lon_0=24 +k=0.9996 +x_0=500000 +y_0=-6000000 +ellps=GRS80 +units=m +no_defs' Warning: [[QgsCoordinateReferenceSystem]]::findMatchingProj -------> no match found in srs.db, trying user db now! Warning: [[QgsCoordinateReferenceSystem]]::findMatchingProj -------> no match found in user db
#7
Updated by Magnus Homann over 15 years ago
- Status changed from Feedback to Closed
- Resolution set to fixed
The WKT is read by the OGR library to an OGR-internal format, and then exported to proj4 string from that OGR format (for projection). I would guess that OGR does not recognize the "LKS92" datum, and assigns no datum.
So, the proj4 string you in the output above IS created from OGR.
I think this bug should be sent to OGR maintainer. The best solution is that OGR converts the LKS92 datum to a +towgs84=0,0,0,0,0,0,0
Note: Now QGIS creates a custom CRS from the proj4 string if no match was found. Unfortunately, as OGR does not supply any datum
#8
Updated by Magnus Homann over 15 years ago
... we can't assume that it is equal to EPSG 3059, where the datum is specified as LKS92 (WKT) or towgs84=0,0,0,0,0,0,0 (our EPSG list)
#9
Updated by hamish - over 15 years ago
#10
Updated by Magnus Homann over 15 years ago
Fixed i18n problems in , it was no possible auto create CRS when i18n characters were used in the description.