this question boost polygon (not boost geometry)
recently trying play geometrical polygon constructions. since boost geometry (a different library deals polygons) not working circumstantially in boost 1.58 though give try boost polygon.
after trying understand library , not getting expected results discovered library works integer coordinates. @ first though limitation input, in fact internal operations , outputs integers, makes output quite quirky, example, intersections polygons deformed (because coordinates of vertices have integers).
a quote main page (emphasis mine):
the coordinate data type template parameter of data types , algorithms provided library, , is expected integral. floating point coordinate data types not supported algorithms implemented in library due fact (sic) achieving floating point robustness implies different set of algorithms , platform specific assumptions floating point representations.
at first though problem between exact , inexact representation tried make work rational (boost rational) types (i figured out wrapper rational class make compile) integer coordinates strict requirement (there parts in code add , substract 1 construct intermediate results).
going integers, had make coordinates big (in integer terms) make discreteness problem disappear. in other words have normalized , forth. well, @ end not useful or convenient thought.
am missing important use of library?
is library intended "pixelated" problems? utility if coordinates restricted integers?
is idea scale coordinates big numbers , renormalize results later geometric applications?
i understand computational geometry floating-points painful, but why library doesn't try compatible exact rationals?
are there real examples of use? (the manual pretty bad @ giving examples) is using library?
bonus question: is abandoned library?
this example of how library behaves integer coordinates:
here example of happens integral polygons, if use small numbers represent coordinates results not geometrically consistent. (the 2 polygons polygon(-2,0)(2,-2)(6,4)(0,2) , polygon(-5,0)(-1,-2)(3,4)(-3,2))
(note how skew comes out.)
but when scale polygons have large integer coordinates results more exact (the 2 polygons polygon(-200,0)(200,-200)(600,400)(0,200) , polygon(-500,0)(-100,-200)(300,400)(-300,200), scaled versions of 2 above.):
edit: learned bit more of computational geometry, apparently robustness of computational geometry difficult problem. 1 of strategies use integer arithmetic. looks boost.polygon takes approach. problems in continuous space should scaled appropriately.
it's not abandoned.
yes it's used (many) people.
one thing seems have solid user base e.g. voronoi diagrams , related algorithms. can find number of questions on too, head on see use for.
bonus answer
you can combine libraries using
#include <boost/geometry/geometries/adapted/boost_polygon.hpp> 
Comments
Post a Comment