Subject: Re: [geometry] snapshot of the future geometry 1.56 release
Date: 2014-02-28 09:53:29
Thank you for your answer. I tested your "rescale to integer" branch and it turns out it fixes quite a lot of things, great job :). In the end, it highlighted that some of my polygons are not simple, thus leading to further crashes in intersections, union_ and alike. I was wondering what was going to be my next step: is there (will there be) a predicate somewhere in boost::geometry that could help filter them out, or even better correct them beforehand? I am studying the Shamos-Hoey Algorithm as a good predicate algorithm on client code side, do you happen to have a better suggestion?
Thanks again for your time.
Wireless Engineering and Propagation
tel. +33 384 544 338
De : Geometry [mailto:geometry-bounces_at_[hidden]] De la part de Barend Gehrels
Envoyé : jeudi 27 février 2014 21:35
À : Boost.Geometry library mailing list
Objet : Re: [geometry] snapshot of the future geometry 1.56 release
yohann.benedic_at_[hidden] wrote On 27-2-2014 16:44:
> Hi Barend,
> Sorry to bother you again. I am facing quite a large amount of crashes with either union_, or difference (and possibly others) when I try them on my large datasets (many hundred thousand polygons processed in various ways, I am actually porting existing working code from GPC to boost/Geometry). Most of what I see have to do with numerical robustness (e.g. computing the difference between two polygons that merely cover each other).
> The ported code is expected to become production code by the end of the semester and it's not going to happen with version 1.54.
> Since you told me a lot of work has been done about it in the future 1.56 release of boost::geometry, I was wondering if I could somehow try it (I believe I should download from https://github.com/boostorg/geometry/tree/develop/include/boost/geometry) to see how stable it has become regarding numerical robustness. The good thing would be that I could focus on reporting relevant crash cases and not the ones that are already fixed in your dev branch.
> What do you think? Is the link I found the right one for that matter?
It is not yet integrated into the "develop" branch. The branch is:
Apart from that the union and other intersection problems should be solved. However, a nasty side effect in some cases is that some spikes are left, I'm trying to fix that too and that is the reason why it is not integrated yet. I cannot say if that is a problem for you.
You are welcome to try it and report your experiences with it.
It is a (more or less) personal branch but still I try to have it as complete as possible, so no compilation errors etc, but it is not daily tested automatically.
Geometry mailing list
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Geometry list run by mateusz at loskot.net