Feature request #2123
wrong projection information when creating a new shapefile
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Low | ||
| Assignee: |  Jürgen Fischer | ||
| Category: | Data Provider | ||
| Pull Request or Patch supplied: | Resolution: | fixed | |
| Easy fix?: | No | Copied to github as #: | 12183 |
Description
(This bug may be related to #1943 and also to #1889, if it isn't even the same.)
Im working with crs epsg 21781. If I create a new shapefile with the "new vecotr layer" tool, the shapefile is missing the towgs84 part in its crs parameters.
1. Open Qgis
2. in project properties set tht crs to epsg 21781/CH1903 (Enable 'on the fly' is also set).
3. in the settings->options->crs set "project wide default crs will be used"
4. with the "new vector layer"-button create a new shapefile and save it.
5. load the created shapefile into qgis
6. open the properties of the new shapefile
-> the crs of the shapefile is missing the towgs84 parameter and therefore it displays on a wrong place in the canvas.I attach the debug output from the console when creating a new shapefile in this way. You will see that from line 1 to 14 all output concering crs has the towgs84 information. As from line 41 on the towgs84 part is missing. So it seems to be a problem of the qgsvectorprovider or ogr.
The crs in the srs.db is ok, also the epsg file of proj.
Currently I'm running r12143.
regards
Cedric
debugoutput_new_shapfile.txt 
- debug output when creating a new shapefile in epsg 21781
(33 KB)
fix_wrong_prj_files.diff
- patch to correct wrong prj files when creating an empty data source. Added a test if its really a shapefile
(1.02 KB)
Associated revisions
[FEATURE] allow specification of CRS when creating shape files (also fixes #2123)
git-svn-id: http://svn.osgeo.org/qgis/trunk/qgis@12259 c8812cc2-4d05-0410-92ff-de0c093fc19c
[FEATURE] allow specification of CRS when creating shape files (also fixes #2123)
git-svn-id: http://svn.osgeo.org/qgis/trunk@12259 c8812cc2-4d05-0410-92ff-de0c093fc19c
shapefile projection fix: save the real projection in .qpj next to the .prj file (fixes #2123 and #2154)
git-svn-id: http://svn.osgeo.org/qgis/trunk/qgis@12274 c8812cc2-4d05-0410-92ff-de0c093fc19c
shapefile projection fix: save the real projection in .qpj next to the .prj file (fixes #2123 and #2154)
git-svn-id: http://svn.osgeo.org/qgis/trunk@12274 c8812cc2-4d05-0410-92ff-de0c093fc19c
History
#1
Updated by cmoe - almost 15 years ago
I stripped the problem down to the call of OGR_DS_CreateLayer of the createEmptyDataSource method in qgsogrprovider.cpp (around linie 1525).
The reference (OGRSpatialReferenceH) we are passing seems to be ok, but the returning layer (OGRLayerH) is missing the towgs84 part in his srs.
This seems to be intentional of ogr because OGR_DS_CreateLayer calls morphToESRI() for the srs (line 568 in gdal/ogr/ogrsf_frmts/shape/ogrshapedatasource.cpp). morphToESRI() removes the towgs84 parameter.
This does not happen, if I export a postgis layer as shapefile or an existing shapefile. But this is done in different way by the QgsVectorFileWriter::writeAsShapefile(). qgsvectorfilewriter.cpp says at line 397, that it doesn't strip the towgs84 parameter.
Would it be possible, to use the QgsVectorFileWriter in the createEmptyDataSource method? According to comment qgsvectorfilewriter.cpp we are already broken with relying on ESRI style prj-files.
#2
Updated by cmoe - almost 15 years ago
I understand the follwing now: If we do writeAsShapefile() ogr responds also with a wrong prj file.
But afer the ogr call qgis just overwrites the prj file with a correct version.
So we may do the same for creating an empty data source. A patch is provided in the attachments.
Please may someone have a look at it, and, if appropriate, apply it.
#3
Updated by Marco Hugentobler almost 15 years ago
Hi Cedric
Thank you for the patch. It might be good to test if format is shapefile, since the method could also be used for other formats (even if this is not the case at the moment).
Otherwise +1 for me to apply the patch.
I'm assigining the ticket to Jürgen, since he is the OGR guru in the dev team.
Regards,
Marco
#4
Updated by cmoe - almost 15 years ago
Hi Marco
I added a test if it's a ESRI Shapefile to the patch. I'm not sure if this the right way to do it, but it works :-)
I added also a little more robustnes to the writing of the new file.
#5
Updated by Jürgen Fischer almost 15 years ago
- Resolution set to fixed
- Status changed from Open to Closed
"applied" in 83d6e0ca (SVN r12260).