#1464: Bug on v.buffer
----------------------+-----------------------------------------------------
Reporter: leonidas | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.2
Component: Vector | Version: svn-trunk
Keywords: v.buffer | Platform: Linux
Cpu: x86-32 |
----------------------+-----------------------------------------------------
Comment(by 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
#1464: Bug on v.buffer
----------------------+-----------------------------------------------------
Reporter: leonidas | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Vector | Version: svn-trunk
Keywords: v.buffer | Platform: All
Cpu: All |
----------------------+-----------------------------------------------------
Changes (by mmetz):
* platform: Linux => All
* cpu: x86-32 => All
* milestone: 6.4.2 => 7.0.0
Comment:
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)?
#1464: Bug on v.buffer
----------------------+-----------------------------------------------------
Reporter: leonidas | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Vector | Version: svn-trunk
Keywords: v.buffer | Platform: All
Cpu: All |
----------------------+-----------------------------------------------------
Comment(by neteler):
Replying to [comment:4 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.
#1464: Bug on v.buffer
----------------------+-----------------------------------------------------
Reporter: leonidas | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Vector | Version: svn-trunk
Keywords: v.buffer | Platform: All
Cpu: All |
----------------------+-----------------------------------------------------
Comment(by martinl):
Replying to [comment:5 neteler]:
> Replying to [comment:4 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.
