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.

  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

Attachments (2)

test21781.zip (14.7 KB ) - added by cmoe 15 years ago.
shapefile with lines and epsg 21781
fix_wrong_prj_files_qgsvecotrfilewriter.diff (1.2 KB ) - added by cmoe 14 years ago.
patch for correcting the shapefiles prj file by overwriting it (constructor). Added a little bit of robustnes when writing the new prj file

Download all attachments as: .zip

Change History (9)

by cmoe, 15 years ago

Attachment: test21781.zip added

shapefile with lines and epsg 21781

comment:1 by lutra, 15 years ago

Hi,

what version of qgis are you using?

Here on 1.3 seems to have no problems.

in reply to:  1 comment:2 by cmoe, 15 years ago

Replying to lutra:

Hi,

what version of qgis are you using?

Here on 1.3 seems to have no problems.

Hi,

i'm using 1.2.0 r11504 and 1.4.0 r11698. It happens on both versions.

comment:3 by lutra, 15 years ago

Cc: homann added
Component: VectorsPython plugins and bindings
Owner: changed from nobody to cfarmer
Platform: RedHatAll
Priority: critical: causes crash or data corruptionmajor: 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 cmoe, 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 cmoe, 14 years ago

Type: bugpatch

by cmoe, 14 years ago

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 cmoe, 14 years ago

Component: Python plugins and bindingsData Provider
Owner: changed from cfarmer to jef

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 cmoe, 14 years ago

Resolution: fixed
Status: newclosed

this should be fixed now in r12259 from Juergen.

Note: See TracTickets for help on using tickets.