Opened 15 years ago
Closed 14 years ago
#1943 closed patch (fixed)
ftools/buffer produce result shape with wrong crs parameters
Reported by: | cmoe | Owned by: | jef |
---|---|---|---|
Priority: | major: does not work as expected | Milestone: | Version 1.4.0 |
Component: | Data Provider | Version: | Trunk |
Keywords: | crs; buffer; ftools | Cc: | homann |
Must Fix for Release: | Yes | Platform: | All |
Platform Version: | Awaiting user input: | no |
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.
- load attached shapefile
- buffer with ftools and buffer distance of 50 meters
- load the resulting shapefile
=> shapefile is misplaced due to missing the towgs84 parameter in the projection
Attachments (2)
Change History (9)
by , 15 years ago
Attachment: | test21781.zip added |
---|
follow-up: 2 comment:1 by , 15 years ago
Hi,
what version of qgis are you using?
Here on 1.3 seems to have no problems.
comment:2 by , 15 years ago
comment:3 by , 15 years ago
Cc: | added |
---|---|
Component: | Vectors → Python plugins and bindings |
Owner: | changed from | to
Platform: | RedHat → All |
Priority: | critical: causes crash or data corruption → major: does not work as expected |
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.
comment:4 by , 14 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.
comment:5 by , 14 years ago
Type: | bug → patch |
---|
by , 14 years ago
Attachment: | fix_wrong_prj_files_qgsvecotrfilewriter.diff added |
---|
patch for correcting the shapefiles prj file by overwriting it (constructor). Added a little bit of robustnes when writing the new prj file
comment:6 by , 14 years ago
Component: | Python plugins and bindings → Data Provider |
---|---|
Owner: | changed from | to
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
comment:7 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
this should be fixed now in r12259 from Juergen.
shapefile with lines and epsg 21781