Feature request #1943
ftools/buffer produce result shape with wrong crs parameters
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 #: | 12003 |
Description
When buffering a shapefile that has epsg 21781 (CH1903) with ftools buffer, the resulting shapefile is lacking the towgs84 parameter in the crs (and the prj-file) and is therefore misplaced.
This seems to be similar to Ticket #1889, but this time is not the creation of a new shapefile affected but the buffer.
1. load attached shapefile
2. buffer with ftools and buffer distance of 50 meters
3. load the resulting shapefile
=> shapefile is misplaced due to missing the towgs84 parameter in the projection
History
#1 Updated by Giovanni Manghi about 15 years ago
Hi,
what version of qgis are you using?
Here on 1.3 seems to have no problems.
#2 Updated by cmoe - about 15 years ago
#3 Updated by Giovanni Manghi about 15 years ago
This is weird.
I'm using qgis 1.3 and 1.4 trunk under Ubuntu 9.04
I apparently see no problems (with or without OTFR enabled), even if as a fact the towgs84 parameter is missing in the resulting layer projection.
I see also that other layers resulting from other ftools operation seem to miss the towgs84 if present in the source layer.
Not sure where the problem may reside, if in the plugin or in the projection component.
#4 Updated by cmoe - almost 15 years ago
The problem I see is, that ogr always strips out the towgs84 parameter when creating a shapefile. See also #2123.
The problem is the call of ogr in the constructor of QgsVectorFileWriter. But the "wrong" or, as ogr it calls, esri style like prj file may be overwritten by qgis. That's what already is done in the QgsVectorFileWriter::writeAsShapefile.
I wrote a little patch to do that, please have a look at it, and, if appropriate, apply it.
The missing parameter is quite cruical, if you are working in epsg21781. In the normal range of the coordinates (600000/200000), the missing parameters leads to a misplacement which is about 100 meters.
#5 Updated by cmoe - almost 15 years ago
I learned from Marco that Jürgen is our OGR guru.:-) Since this is an ogr issue, I assign the ticket now to him.
regards
Cédric
#6 Updated by cmoe - almost 15 years ago
- Resolution set to fixed
- Status changed from Open to Closed
this should be fixed now in 83d6e0ca (SVN r12260) from Juergen.