Bug report #2089
Buffer produces incorrect results with multipart vectors
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Low | ||
| Assignee: |  cfarmer - | ||
| Category: | Python plugins | ||
| Affected QGIS version: | Regression?: | No | |
| Operating System: | All | Easy fix?: | No |
| Pull Request or Patch supplied: | Resolution: | invalid | |
| Crashes QGIS or corrupts data: | Copied to github as #: | 12149 |
Description
To reproduce:
1. create a new project in QGIS,
2. add layer kirdem2.epg4326.shp using Layers -> Add vector layer...,
3. Tools -> Geoprocessing tools -> Buffer(s), set buffer distance to -0.0003, choose output file, click OK
Expected result: an inner buffer of the polygons in platte carree distance (not real distance, as interpreting degrees as meters would be ambiguous)
Actual result: certainly not a buffer neither in platte carree distance nor in real geodetic distance nor any other projection. In some places, the buffer exceeds the original polygon border (see qgis_buffer_bug1.png); in some places, the buffer has "pixel artifacts" (qgis_buffer_bug1.png); some islands are missing altogether (qgis_buffer_bug2.png).
The input data kirdem2.epg4326.shp is part of the publicly available dataset '01.09.2009a. asustusüksus SHP' (zip - 13,65 MB, 6.11.2009 ) on
http://www.maaamet.ee/index.php?lang_id=1&page_id=272&menu_id=0
(I cut a small part out and converted to EPSG:4326 using QGIS).
History
#1
Updated by Giovanni Manghi almost 15 years ago
If you transform your vector from multipart to singleparts the buffer results ok.
This may be a simple workaround or it may be simply necessary, I'm not sure how buffer tools is supposed to work with multipart vectors.
Carson?
#2
Updated by Giovanni Manghi over 14 years ago
awaiting Carson reply, I'll push this to 1.6 as in any case there is a workaround
#3
Updated by cfarmer - about 14 years ago
- Resolution set to invalid
- Status changed from Open to Closed
Tested using f13d3f35 (SVN r14368).
I am unable to reproduce this error. Looking at the areas described in this ticket, results appear to be as expected. I suspect this was a GEOS error, but appears to now have been fixed (GEOS version?). Please test and confirm if this now works.
I am going to close this as "invalid" because this is now a relatively old ticket, and appears to now be invalid, however, if it is still a problem, please reopen this ticket.
Carson