search

qissue-bot / QGIS

QGIS is a free, open source, cross platform (lin/win/mac) geographical information system (GIS)
http://qgis.org
GNU General Public License v2.0
0 stars 0 forks source link

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

Closed qissue-bot closed 5 years ago

qissue-bot commented 5 years ago

Author Name: mesajs - (mesajs -) Original Redmine Issue: 2154, https://issues.qgis.org/issues/2154

Original Assignee: nobody -

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.

qissue-bot commented 5 years ago

Original Redmine Comment Author Name: Frank Warmerdam - (Frank Warmerdam -) Original Date: 2009-11-26T17:04:10.000Z

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?

qissue-bot commented 5 years ago

Original Redmine Comment Author Name: mesajs - (mesajs -) Original Date: 2009-11-26T17:47:33.000Z

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.

qissue-bot commented 5 years ago

Original Redmine Comment Author Name: Frank Warmerdam - (Frank Warmerdam -) Original Date: 2009-11-26T18:39:00.000Z

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.

qissue-bot commented 5 years ago

Original Redmine Comment Author Name: Jürgen Fischer (Jürgen Fischer) Original Date: 2009-11-26T23:23:23.000Z

Replying to "mesajs":/issues/show/2154:

Problem occurs in QGIS version 1.3 and 1.4.

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

qissue-bot commented 5 years ago

Original Redmine Comment Author Name: mesajs - (mesajs -) Original Date: 2009-11-27T00:40:38.000Z

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.

qissue-bot commented 5 years ago

Original Redmine Comment Author Name: cmoe - (cmoe -) Original Date: 2009-11-27T02:36:59.000Z

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

qissue-bot commented 5 years ago

Original Redmine Comment Author Name: cmoe - (cmoe -) Original Date: 2009-11-27T03:50:33.000Z

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

qissue-bot commented 5 years ago

Original Redmine Comment Author Name: Frank Warmerdam - (Frank Warmerdam -) Original Date: 2009-11-27T05:00:29.000Z

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.

qissue-bot commented 5 years ago

Original Redmine Comment Author Name: mesajs - (mesajs -) Original Date: 2009-11-27T11:44:41.000Z

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

qissue-bot commented 5 years ago

Original Redmine Comment Author Name: Jürgen Fischer (Jürgen Fischer) Original Date: 2009-11-28T07:15:25.000Z

qissue-bot commented 5 years ago

Original Redmine Comment Author Name: cmoe - (cmoe -) Original Date: 2009-11-29T06:38:20.000Z

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".

qissue-bot commented 5 years ago

Original Redmine Comment Author Name: cmoe - (cmoe -) Original Date: 2009-11-29T06:46:21.000Z

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

qissue-bot commented 5 years ago

Original Redmine Comment Author Name: Jürgen Fischer (Jürgen Fischer) Original Date: 2009-11-29T07:35:46.000Z

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 commit:acde2443 (SVN r12291).

qissue-bot commented 5 years ago

Original Redmine Comment Author Name: mesajs - (mesajs -) Original Date: 2009-11-29T20:58:35.000Z

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???).

  4. 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