layer with non-standard CRS doesn't get its CRS set correctly on loading file or project

[smizuno]

The situation:

1. project CRS set to epsg:26915 with on-the-fly projection enabled; a layer in epsg:26915 for reference.

2. A shape file in Washington county coordinates, feet (Minnesota) with a .prj file.

3. a custom CRS defining the Washington county coordinates is defined.

Steps to show the problems:

1. Add Vector Layer - choose the shape file noted above.

2. the dialog to set the layer CRS appears - choose the custom CRS noted above.

3. the layer is added, but is not projected in the proper location.

4. check the Layer Properties, General or Metadata tab - the CRS listed is WGS84 parameters (depends on QGIS settings).

5. on the General tab of Layer Properties change the CRS to the custom CRS noted above.

6. now the layer projects in the proper location.

7. save the project

8. load the project

9. the layer is projected in the wrong location.

10. check the CRS in layer properties - it is wrong.

11. set the custom CRS for the layer.

12. now the layer is projected correctly.

There are three problems here:

First, the .prj file wasn't used like it is in some previous versions of QGIS. 0.9.1 used the .prj file; 0.10.0 doesn't, but at least set the CRS from the dialog.

Second, the CRS set via the dialog presented on layer loading isn't saved.

Third, a project containing a Washington county coordinates layer is loaded incorrectly.

Some details about loading the saved project: after loading, the CRS is not correct - the x_0 and y_0 values are wrong (they are the epsg:26915 coordinates of the lat_0, lon_0 parameters in the Washington county coordinates CRS)

The project file has the correct values.

the custom CRS: +proj=tmerc +lat_0=44.74583333333334 +lon_0=-92.83333333333331 +k=1.000040 +x_0=152406.3759 +y_0=30481.27509999999 +ellps=GRS80 +datum=NAD83 +to_meter=0.3048006096012192 +no_defs

as loaded from the project file: +proj=tmerc +lat_0=44.74583333333334 +lon_0=-92.83333333333331 +k=1.00004 +x_0=500019.9182652503 +y_0=100003.9833905833 +ellps=GRS80 +datum=NAD83 +to_meter=0.3048006096012192 +no_defs

my system: Windows XP, GEOS 3.0.0, GDAL 1.5.2, QGIS r9061

I haven't tested on Linux yet.

[cgsbob]

I am running r9060 on a Ubuntu 8.04 X86_64 system with qt4.4 and I'm having the same problem. I mentioned this problem in IRC a few days ago and this is what I wrote:

<CGI617> Now I have another weird problem. I load a latlon nad27 quad map of California and a geology map in state plane zone 3 nad27 with otf turned on. Saved it in a project and reran qgis. <CGI617> otf is still on and each layer pointing to the right projection, but the layers don't over lay each other. Looking at the metadata of the geology layer shows that the projection has changed. In the proj string x_0=2000000 instead of 609601.2192024384. <CGI617> I click on the layer properties general tab and click on Change CRS and I can see that the right projection is selected. After clicking on OK and then OK on the layer properties dialog box, I can see the geology feature move to the correct position. <CGI617> it seems that qgis assumes that the projection used meters instead of feet.

Replying to smizuno:

The situation: 1. project CRS set to epsg:26915 with on-the-fly projection enabled; a layer in epsg:26915 for reference. 2. A shape file in Washington county coordinates, feet (Minnesota) with a .prj file. 3. a custom CRS defining the Washington county coordinates is defined. Steps to show the problems: 1. Add Vector Layer - choose the shape file noted above. 2. the dialog to set the layer CRS appears - choose the custom CRS noted above. 3. the layer is added, but is not projected in the proper location. 4. check the Layer Properties, General or Metadata tab - the CRS listed is WGS84 parameters (depends on QGIS settings). 5. on the General tab of Layer Properties change the CRS to the custom CRS noted above. 6. now the layer projects in the proper location. 7. save the project 8. load the project 9. the layer is projected in the wrong location. 10. check the CRS in layer properties - it is wrong. 11. set the custom CRS for the layer. 12. now the layer is projected correctly. There are three problems here: First, the .prj file wasn't used like it is in some previous versions of QGIS. 0.9.1 used the .prj file; 0.10.0 doesn't, but at least set the CRS from the dialog. Second, the CRS set via the dialog presented on layer loading isn't saved. Third, a project containing a Washington county coordinates layer is loaded incorrectly. Some details about loading the saved project: after loading, the CRS is not correct - the x_0 and y_0 values are wrong (they are the epsg:26915 coordinates of the lat_0, lon_0 parameters in the Washington county coordinates CRS) The project file has the correct values. the custom CRS: +proj=tmerc +lat_0=44.74583333333334 +lon_0=-92.83333333333331 +k=1.000040 +x_0=152406.3759 +y_0=30481.27509999999 +ellps=GRS80 +datum=NAD83 +to_meter=0.3048006096012192 +no_defs as loaded from the project file: +proj=tmerc +lat_0=44.74583333333334 +lon_0=-92.83333333333331 +k=1.00004 +x_0=500019.9182652503 +y_0=100003.9833905833 +ellps=GRS80 +datum=NAD83 +to_meter=0.3048006096012192 +no_defs my system: Windows XP, GEOS 3.0.0, GDAL 1.5.2, QGIS r9061 I haven't tested on Linux yet.

[cgsbob]

To illustrate the problem:

1) load  ftp://ftp2.census.gov/geo/tiger/TIGER2007FE/06_CALIFORNIA/fe_2007_06_county.zip using the default CRS (EPSG id 4269)

2) load  ftp://ftp.consrv.ca.gov/pub/dmg/shezp/Contra%20Costa%20County/Walnut_Creek/ and set any of the shapefiles with the EPSG Id of 26743.

3) Enable 'on the fly' CRS transformation and Zoom Full and you will see that 2) is now near Hawaii :-)

4) View 2) metadata and note that +x_0=2000000

5) View the general tab and click on 'Change CRS'. Note that +x_0=609601.2192024384

6) Click Ok to quit Projection Selector and Ok to close Layer Properties and you will see that 2) pops into the right place!!

[jef]

fixed in r9071

[warmerdam]

jef suggested there is a bug with doing multiple importFromProj4()'s from a foot based coordinate system. Reviewing the code this seems likely though I haven't tried to reproduce the details. OGR ticket filed as:

 http://trac.osgeo.org/gdal/ticket/2533

[anonymous]

Milestone Version 1.0.0 deleted