I very like the idea behind BGL but I experience some unexpected behaviour using the library. I'm using area and intersection algorithms with a custom point type of int32 coordinate type. I've found that these algorithms produce wrong results for medium and large coordinate values (probably due to integer overflow).
For the area algorithm I tried to specify ResultType as double but it didn't help because internal calculations are executed in the coordinate type (like get<1> - get<0>) where overflow occurs. My last solution is to specify the double coordinate type in the traits and perform some rounding in the set function. Thus, all the calculations will be performed using the double type.
I have some questions related to the design of the bgl.
1. Is it intended to produce calculations using the coordinate type or are there some ways to specify the type for calculations? Thus, to distinguish storage types and calculation types?
2. I think the only coordinate type is not enough. At least there should be some other type like length (which can be unsigned). How is it matched with the current design of BGL?
3. Is my solution to specify double type as the coordinate type in the traits correct? Maybe some other better solutions exist?
Thank you in advance,