Bug report #2154

Not correctly creating (or reading) proj file for CRS for EPSG 2193

Added by mesajs - almost 10 years ago. Updated almost 10 years ago.

Status:Closed
Priority:Low
Assignee:nobody -
Category:Projection Support
Affected QGIS version: Regression?:No
Operating System:Windows Easy fix?:No
Pull Request or Patch supplied: Resolution:fixed
Crashes QGIS or corrupts data: Copied to github as #:12214

Description

Problem occurs in QGIS version 1.3 and 1.4.

To reproduce:

1. Create project with CRS set to EPSG 2193 (NZGD2000/New Zealand Transverse Mercator 2000)

2. Use "New vector layer" to create a new shapefile.

Result: The new shapefile is added to QGIS with a "user defined coordinate system" with the following definition: +proj=tmerc +lat_0=0 +lon_0=173 +k=0.9996 +x_0=1600000 +y_0=10000000 +ellps=GRS80 +units=m +no_defs

The .prof file created for the shapefile is attached.

test_proj.prj (400 Bytes) mesajs -, 2009-11-26 05:34 PM

Associated revisions

Revision b2970fb2
Added by Jürgen Fischer almost 10 years ago

fix #2154 again:
- ogr provider doesn't create shapefiles without .shp extension anymore (OGR
used to create a subdirectory in that case)
- automatically add .shp extension when using the new vector layer dialog

git-svn-id: http://svn.osgeo.org/qgis/trunk/[email protected] c8812cc2-4d05-0410-92ff-de0c093fc19c

Revision acde2443
Added by Jürgen Fischer almost 10 years ago

fix #2154 again:
- ogr provider doesn't create shapefiles without .shp extension anymore (OGR
used to create a subdirectory in that case)
- automatically add .shp extension when using the new vector layer dialog

git-svn-id: http://svn.osgeo.org/qgis/[email protected] c8812cc2-4d05-0410-92ff-de0c093fc19c

History

#1 Updated by Frank Warmerdam - almost 10 years ago

I'm not clear on what actual problem you are encountering. Is the .prj file you attached not one that was created by this process?

#2 Updated by mesajs - almost 10 years ago

Replying to [comment:1 warmerdam]:

I'm not clear on what actual problem you are encountering. Is the .prj file you attached not one that was created by this process?

Yes, it is the one created by the process. The problem is that when QGIS loads the shapefile, it reports (according to the layer properties dialog) that the CRS is user defined. But it is not user defined, it should show as EPSG 2193.

I am also surprised that the .prj file has "D_unknown" as part of the DATUM definition. Would have expected something like NZGD2000, but then I don't really know what to expect here.

#3 Updated by Frank Warmerdam - almost 10 years ago

Tony,

OK, that helps me.

I have only limited familiarity with the mechanisms in QGIS for spatial reference system handling, though I'm quite familiar with PROJ.4 and the OGRSpatialReference class from GDAL (used to some extent).

I see the current "trunk" PROJ.4 expansion of EPSG:2193 in GDAL is:

+proj=tmerc +lat_0=0 +lon_0=173 +k=0.9996 +x_0=1600000 +y_0=10000000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

This is similar to what QGIS used as a PROJ.4 string, except without the +towgs84 string indicating that the datum should be considered equivelent to WGS84. I'm not sure why that is missing, perhaps something is older in your QGIS environment.

This PROJ.4 string (in either form) provides no identifying information that would indicate the datum is NZGD2000 so there is no way to fill in the .prj file properly with a datum name. Likewise, there is essentially not enough information left to relate the .prj file back to EPSG:2193.

I assume QGIS is using the PROJ.4 string as a working representation of the spatial reference system, but this is a rather poor idea if it is desirable to relate things back to EPSG since PROJ.4 is quite inexpressive with regard to some details in the original EPSG definition or even the WKT definition.

I think I'll leave this for someone more savvy with QGIS coordinate system support to comment, but at things stand there is little to be done to make this work without significant code restructuring.

#4 Updated by Jürgen Fischer almost 10 years ago

Replying to mesajs:

Problem occurs in QGIS version 1.3 and 1.4.

1.4 meaning >= 83d6e0ca (SVN r12260)? This might be a duplicate of #2123.

#5 Updated by mesajs - almost 10 years ago

Initial test was using R12236.

Have just downloaded R12266 and problem is still there. No towgs84 parameter appears in the .prj file, and the layer still loads as a user defined projection.

Tony

PS. Tried manually editing the .prj file, adding the towgs84 parameter. The layer then correctly shows in QGIS as EPSG 2193 (NZGD2000/NZTM2000). So problem is in the creation of the .prj file.

#6 Updated by cmoe - almost 10 years ago

Hi Tony

please try to give a full shapefile name with extension, eg. "myshapefile.shp" when asked in the dialog and report back.

For me I works this way. I does not work, if I only give the name ("myshapefile"). But I work under linux and not vista.

Jürgen: does the uri have an ".shp" ending when not using the name with extension? If not, this may be the problem as createEmtpyDataSource() in QgsOgrProvider tests for the last four characters of the uri and only then the prj files is overwritten.

regads
Cédric

#7 Updated by cmoe - almost 10 years ago

Replying to [comment:3 warmerdam]:

This is similar to what QGIS used as a PROJ.4 string, except without the +towgs84 string indicating that the datum should be considered equivelent to WGS84. I'm not sure why that is missing, perhaps something is older in your QGIS environment.

Hi Frank

AFAIK, Qgis uses QGR to create new vectorfiles/shapefiles by calling OGR_DS_CreateLayer. The ESRI Shapefile driver of OGR then strips out the towgs84 parameter in his morphToESRI() method. At least that's what I understand.

regards
Cédric

#8 Updated by Frank Warmerdam - almost 10 years ago

Cédric,

Yes, OGR does strip the towgs84 parameter when writing the .prj file. TOWGS84 is not a legal construct in an ESRI Projection Engine string (for .prj files). The Shapefile .prj format does not support preserving explicit datum shift values and doing so may make the .prj file unreadable in ArcGIS.

This may have implications for #2123 as well though I did not follow all the details of that ticket.

In general, you cannot depend on OGR formats to preserve spatial references in very precise way. Different formats represent SRSes differently and may or may not preserve specific information like datum names, datum shift parameters and EPSG associations. QGIS ought to accomodate this as best possible.

#9 Updated by mesajs - almost 10 years ago

Cedric

You are right. Providing an explicit extension does fix the problem.

Even stranger: If I do not give the extension, then QGIS creates a subfolder of the same name and places the shapefile components there.

EG. If I select folder "C:\\QGIS" and save as "myshapfile.shp" (explicit extension), then I get files "C:\\QGIS\\myshapefile.shp", "C:\\QGIS\\myshapefile.prj" etc. But if I select folder "C:\\QGIS" and save as "myshapfile" (no extension), the files are "C:\\QGIS\\myshapefile\\myshapefile.shp" etc. - folder C:\\QGIS\\myshapefile is created.

Is this another bug?

Tony

#10 Updated by Jürgen Fischer almost 10 years ago

  • Status changed from Open to Closed
  • Resolution set to fixed

#11 Updated by cmoe - almost 10 years ago

  • Status changed from Closed to Feedback
  • Resolution deleted (fixed)

Hi Jürgen

thanks for the fix but one little glitch: If the extension is not specified in the file dialog (eg. "myshapefile" and not "myshapefile.shp"), the shapefile is written to the directory "myshapefile" but the .qpj file is written one directory above. This way, Qgis is not aware of the .qpj file, if I load the shapefile again with "add Vector Layer".

#12 Updated by cmoe - almost 10 years ago

Hi Tony

this is the behaviour of QGIS since I'm working with it, and I think this is intentional. ESRI Shapefiles may contain up to 9 or so different files, and I like it to have them together in one folder.

On the other hand, working with the ftools, this doesn't happen. The ftools just write a created layer in the choosen folder and the given name without creating any subfolder if the extension is missing.
Having a consistent behaviour wouldn't be a bad idea...

Hm, I think I will file an enhancment on this, if there isn't one already.

regards Cédric

#13 Updated by Jürgen Fischer almost 10 years ago

  • Resolution set to fixed
  • Status changed from Feedback to Closed

Hi Cédric,

Replying to [comment:11 cmoe]:

thanks for the fix but one little glitch: If the extension is not specified in the file dialog (eg. "myshapefile" and not "myshapefile.shp"), the shapefile is written to the directory "myshapefile" but the .qpj file is written one directory above. This way, Qgis is not aware of the .qpj file, if I load the shapefile again with "add Vector Layer".

should be fixed in acde2443 (SVN r12291).

#14 Updated by mesajs - almost 10 years ago

Replying to [comment:12 cmoe]:
Cédric

I like the idea of raising an enhancement. Could be extended to cover other inconsistencies in "save" dialogs:

1. Behavior should not depend on whether or not user types in the .shp extension

2. All dialogs should behave the same. Like ftools, "Save as shapefile" (on layer menu) does not create a sub-directory, but Table Manager plugin does).

3. The qml file (save default layer properties) is added to level above above the new sub-directory (also fixed in R12290???).

3. Print composer "save" dialogs for saving maps as image, pdf, or SVG do not add extensions. But "Save as image" from the file menu on the main main qgis window does add the extension

Tony

Also available in: Atom PDF