Bug report #5176
Wrong projections for custom CRS
| Status: | Closed | ||
|---|---|---|---|
| Priority: | High | ||
| Assignee: | - | ||
| Category: | Projection Support | ||
| Affected QGIS version: | master | Regression?: | No |
| Operating System: | Any | Easy fix?: | No |
| Pull Request or Patch supplied: | No | Resolution: | |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 14923 |
Description
Background:
Any unrecognised CRS from maps are registered as a new Custom CRS with a new ID (starting from 100000). This information is kept somewhere in QGIS configuration files.
E.g. – opening the example shapefile “sample_points” will add a new custom CRS. Let's suppose that the first free ID is 100001. Let's create a new project with this shape file layer. The information added to the QGIS project file will be as follows:..
<datasource>./sample_points.shp</datasource>
<layername>sample_points</layername>
<srs>
<spatialrefsys>
<proj4>+proj=tmerc +lat_0=0 +lon_0=24 +k=0.9996 +x_0=500000 +y_0=0 +ellps=GRS80 +units=m +no_defs</proj4>
<srsid>100001</srsid>
<srid>0</srid>
<authid>USER:100001</authid>
<description> * Ģenerēts CRS (+proj=tmerc +lat_0=0 +lon_0=24 +k=0.9996 +x_0=500000 +y_0=0 +ellps=GRS80 +units=m +no_defs)</description>
<projectionacronym>tmerc</projectionacronym>
<ellipsoidacronym>GRS80</ellipsoidacronym>
<geographicflag>false</geographicflag>
</spatialrefsys>
</srs>
..
The Problem
Let's suppose we send this project (created in the first PC) file and shape file to another user. The second user uses the second PC. Let's suppose the other user is very active one. :) He has used several maps with different unrecognised CRS. So custom CRS with following IDs are presented in the system: 100000, 100001, 100002, 100003. And, of-course, 100001 does not mean the same CRS as it was on the first PC.
Now guess which projection definition will be used in the second PC. :( The Quantum GIS is projecting the sample_points using definition from the the second PC not from the project file or shape file itself.
Repeatability
100 %. Tested versions: 1.7.1 (Ubuntu 9.10), 1.7.4 (OSGeo4W) , Master (OSGeo4W and compiled from source for Fedora 14 x 64).
It's easy to reproduce this bug with any QGIS version. Add as a new layer the attached shape-file. A new custom CRS should be added. Save the project. Close QGIS. Open QGIS. Go to CRS customisation dialogue (Setting/Custom CRS). Change any parameters of the newly created projection, e.g., y_0=0 to y_0=400. Open the saved project. The layer “sample_points” is now moved 400 meters towards north.
Possible bug-fix.
In project files for custom CRS the following information should not be saved: <authid> and <srsid>. At least, <proj4> must be with higher priority then the <authid> and <srsid>.
History
#1
Updated by zirneklitis - over 12 years ago
Let's suppose an another user uses the third PC. He has never used unrecognised CRS and he has no customised CRS. If the above QGIS project is opened on this third PC, the result is confusing. Now the EPSG:2100 - GGRS87 / Greek Grid is used for the “sample_points".
#2
Updated by Brian Freed over 12 years ago
I can confirm this issue. Wish I'd seen this before I spend my morning tracking it down! Not only is this a display problem, but however QGIS writes to Spatialite, it's not tripping the CRS trigger. In other words, we have a field template that should use a customized reference system (project spans 2 UTM zones, and accuracy not super critical). This custom CRS is in the Spatialite db as srid=99001, and the lines table is defined as such. But last week, on a different user's laptop, when he grabbed the template, QGIS matched the unknown CRS with "NAD83 Pennsylvania State Plane South." The user did the whole design, and QGIS happily saved it out, and Spatialite happily accepted it, but the coordinates written into the database are indeed PA State Plane values, not the 99001 values.
[solution: discard geometry column, setsrid=2271, transform to 99001, recovergeometrycolumn]
zirneklitis:
2 bits I can add to help with a workaround for now:
1. (Windows only) the user CRS are stored in an SQLite database - C:\\Documents and Settings\\UserName\\.qgis\\qgis.db, the tbl_srs table.
2. Opening the .qgs file in a text editor and deleting all the <spatialrefsys> tags for your project and any affected layer(s) except for the <proj4> line(s) will prevent QGIS from linking the unknown CRS with whatever "100000" happens to be.
With the user-generated 10000x tags deleted, opening the file under a different user name or on a different pc results in QGIS creating a new CRS that matches the Proj4 parameters.
It does seem like if it sees a custom CRS that exactly matches the Proj4 parameters, it will use it. That's good, as I was afraid of making a new 10000x number every time I open a file.
#3
Updated by Gavin Fleming over 12 years ago
I can confirm this issue. It's well-described above. It has been around since at least June 2011. Layers shouldn't be saved in the .qgs file referencing a CRS ID unless it is a standard / provided CRS ID. Custom or generated CRS's should be referenced by full proj4 string.
#4
Updated by Jürgen Fischer over 12 years ago
- Status changed from Open to Closed
Fixed in changeset 56808d91a12ddb33b1d173778f3b47b136876093.