Opened 7 years ago
Closed 7 years ago
#3438 closed defect (fixed)
v.buffer silently ignores options depending on buffering alhorithm in use
Reported by: | marisn | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 7.4.0 |
Component: | Vector | Version: | svn-trunk |
Keywords: | v.buffer, GEOS | Cc: | |
CPU: | Unspecified | Platform: | Unspecified |
Description
At the moment user gets no warning if some of his input parameters (i.e. minordistance, angle) are ignored due to use of GEOS instead of native buffering algorithm. v.buffer should fail with a fatal error if user has provided unsupported input parameters.
Current approach of setting environmental variable to switch between GEOS and native algorithms is also suboptimal, as setting env on GNU/Linux is easy and common, while setting on Windows is uncommon thus hard. A flag would be better approach.
Change History (3)
comment:1 by , 7 years ago
comment:2 by , 7 years ago
Replying to marisn:
At the moment user gets no warning if some of his input parameters (i.e. minordistance, angle) are ignored due to use of GEOS instead of native buffering algorithm. v.buffer should fail with a fatal error if user has provided unsupported input parameters.
v.buffer prints now (trunk r71724) warnings if options are used that apply only to the native, deprecated algorithm. The manual is updated accordingly.
Current approach of setting environmental variable to switch between GEOS and native algorithms is also suboptimal, as setting env on GNU/Linux is easy and common, while setting on Windows is uncommon thus hard. A flag would be better approach.
This is by purpose to make it difficult to use the buggy native algorithm. The mechanism with an environmental variable exists only in case someone wants to fix and test the native algorithm.
comment:3 by , 7 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Seems to be solved, feel free to reopen if needed.
"tolerance" parameter also works only with the native algorithm.