Bug report #10808
regression with CRS matching
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: | - | ||
| Category: | Projection Support | ||
| Affected QGIS version: | 2.4.0 | Regression?: | No |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | up/downstream |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 19187 |
Description
Open the attached shapefile, which was generated by QGIS and hence has valid prj and qpj files that QGIS should recognise. Recent versions (2.0) did do this correctly. However now the CRS is now recognised and appears blank. It should be finding a match with
South African CRS : HBK_NO_19
History
#1
Updated by Jürgen Fischer over 10 years ago
- Category set to Projection Support
#2
Updated by Giovanni Manghi over 10 years ago
- Status changed from Open to Feedback
When you add that shapefile to QGIS the programs will add a new custom CRS, it says it clearly in the log
Saved user CRS [+proj=tmerc +lat_0=0 +lon_0=19 +k=1 +x_0=0 +y_0=0 +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs]
This means that QGIS is not matching this CRS to anyone in its CRS database, in fact if you look for the HBK_NO_19 definition you will see that the definition it is slightly different.
+proj=tmerc +lat_0=0 +lon_0=19 +k=1 +x_0=0 +y_0=0 +axis=enu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
If you give manually your layer the HBK_NO_19 CRS and re-save it again with the HBK_NO_19 CRS you will see that the result (as you say) has a "different" CRS because the "+axis=enu" part is missing.
But if you do the same operation with gdal/ogr (ogr2ogr) you will see that the same will happen, so if it is a bug it doesn't seems a qgis one.
#3
Updated by Giovanni Manghi about 10 years ago
- Resolution set to up/downstream
- Status changed from Feedback to Closed
closing for lack of feedback, please reopen if necessary.