Opened 12 years ago

Closed 10 years ago

#1464 closed defect (fixed)

Bug on v.buffer

Reported by: leonidas Owned by: grass-dev@…
Priority: critical Milestone: 7.0.0
Component: Vector Version: svn-trunk
Keywords: v.buffer Cc:
CPU: All Platform: All

Description

Errors in output of v.buffer

Change History (9)

comment:1 by martinl, 12 years ago

No description, no sample data, no screenshots. This bug-report is useless.

comment:2 by leonidas, 12 years ago

Ok, 2 screenshots:

  1. buffer with grass: http://www.geographer.gr/buffer/grass_buffer.jpeg
  1. buffer with qgis (ftools): http://www.geographer.gr/buffer/qgis_buffer.jpeg

And here is the vector map as ascii file (epsg code:2100): http://www.geographer.gr/buffer/data.asc.zip

comment:3 by marisn, 12 years ago

Issue description is incomplete. It lacks exact location of failure, buffer size.

I was able to reproduce issue with 100 m buffer, still for other feature. Failing areas have centroids with FIDs: 7945, 7937, 7936 (upper right corner of dataset)

I was unable to find a way how to export only those areas to separate file to ease testing. Still I found a dozen ways how it's not possible to do that ;)

comment:4 by mmetz, 12 years ago

CPU: x86-32All
Milestone: 6.4.27.0.0
Platform: LinuxAll

Fixed in trunk in r51580, as long as GRASS is compiled with GEOS. Neither one of the two GRASS-internal buffering methods is working correctly. Moreover, the GEOS method is the only one allowing for internal buffers with negative distances. Should we disable v.buffer if GEOS is not available (rather have no result than a wrong result)?

Markus M

in reply to:  4 ; comment:5 by neteler, 12 years ago

Replying to mmetz:

Fixed in trunk in r51580, as long as GRASS is compiled with GEOS. Neither one of the two GRASS-internal buffering methods is working correctly. Moreover, the GEOS method is the only one allowing for internal buffers with negative distances. Should we disable v.buffer if GEOS is not available (rather have no result than a wrong result)?

I suppose that GEOS is available for all relevant platforms nowadays (and it became official OSGeo project yesterday). So I support this suggestion.

in reply to:  5 comment:6 by martinl, 10 years ago

Replying to neteler:

Replying to mmetz:

Fixed in trunk in r51580, as long as GRASS is compiled with GEOS. Neither one of the two GRASS-internal buffering methods is working correctly. Moreover, the GEOS method is the only one allowing for internal buffers with negative distances. Should we disable v.buffer if GEOS is not available (rather have no result than a wrong result)?

I suppose that GEOS is available for all relevant platforms nowadays (and it became official OSGeo project yesterday). So I support this suggestion.

+1 for disabling v.buffer when GRASS not compiled against GEOS.

comment:7 by neteler, 10 years ago

Priority: normalcritical

See also #1343

comment:8 by neteler, 10 years ago

v.buffer has been rebased on GEOS (now also for GRASS 6.4.svn in r59970).

Please test the updated version of v.buffer compiled with GEOS support.

comment:9 by neteler, 10 years ago

Resolution: fixed
Status: newclosed

Closing as fixed.

Note: See TracTickets for help on using tickets.