QGIS » QGIS Application

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?

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.

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.

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.

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.

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

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

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.

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

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

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