Bug on v.buffer

[leonidas]

Errors in output of v.buffer

[martinl]

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

[leonidas]

Ok, 2 screenshots:

1. buffer with grass: ​http://www.geographer.gr/buffer/grass_buffer.jpeg

2. 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

[marisn]

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 ;)

[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)?

Markus M

[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.

[martinl]

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.

[neteler]

See also #1343

[neteler]

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.

[neteler]

Closing as fixed.