Geometry Boost List: [ggl] [Fwd: [boost] GGL Review Results]

Subject: [ggl] [Fwd: [boost] GGL Review Results]
From: Ivan Marin (ispmarin)
Date: 2009-11-28 14:42:27

Congratulations!

Ivan Marin

Laborat?rio de Hidr?ulica Computacional - LHC
Departamento de Hidr?ulica e Saneamento - SHS
Escola de Engenharia de S?o Carlos - EESC
Universidade de S?o Paulo - USP

http://albatroz.shs.eesc.usp.br
[phone]

2009/11/28 Stephen Leary <sleary_at_[hidden]>

> Congratulations :)
>
> On Sat, Nov 28, 2009 at 6:53 PM, Barend Gehrels <Barend.Gehrels_at_[hidden]>wrote:
>
>>  Hi all,
>>
>> It's a pleasure for me to announce that GGL has been accepted into Boost.
>> See below the review report.
>>
>> Best regards, Barend
>>
>>
>>
>> -------- Original Message --------  Subject: [boost] GGL Review Results  Date:
>> Sat, 28 Nov 2009 11:34:44 -0600  From: Hartmut Kaiser
>> <hartmut.kaiser_at_[hidden]> <hartmut.kaiser_at_[hidden]>  To:
>> <boost_at_[hidden]> <boost_at_[hidden]>,
>> <boost-users_at_[hidden]> <boost-users_at_[hidden]>,
>> <boost-announce_at_[hidden]> <boost-announce_at_[hidden]>
>>
>> Hi all,
>>
>> The review of the Generic Geometry Library is over now. We have had vibrant
>> discussions with regards to the library itself. In addition those stirred up
>> a lot of controversial discussion about the Boosts review process. In this
>> review results I will concentrate on the library at hands.
>>
>> Formally this review ended with 12 YES and 2 NO votes. This result reflects
>> the overall discussion and the general consensus of this library being worth
>> to be included into Boost.
>>
>> Based on this result and the discussions the Generic geometry Library has
>> been formally accepted into Boost.
>>
>> It is worth highlighting that most of the reviewers emphasized the excellent
>> quality of the library design. Here are some quotes:
>> - "The design is very clear. I think it can serve as a standard example of
>> how to cover a big non trivial problem domain using meta-programming,
>> partial specialization and tag dispatch to make it uniformly accessible by a
>> set of generic algorithms."
>> - "The design looks clear enough so that I was able to understand about what
>> was being done. Adding concept checking is a good idea. It also surely is a
>> modern generic design."
>> - "I am quite pleased with the use of tag-dispatching and strategies. I was
>> happy to see this approach taken and by looking at the documentation and
>> source code it seems sound. I believe this approach offers the greatest
>> latitude for a generic library."
>>
>> At the same time the 2 NO votes reflect a couple of shortcomings which still
>> need to be addressed before final inclusion into SVN. Here is a list of
>> contingencies noted by the reviewers:
>>
>> - Robustness: algorithmic robustness and arithmetic stability have been
>> discussed widely. The consensus of the reviewers is that all algorithms need
>> to be robust and that the user should be able to make sure all calculations
>> are arithmetically stable. GGL addresses arithmetic stability by allowing to
>> instantiate all algorithms with arbitrary number types. But it turns out not
>> the entire library has been converted to use this scheme yet. Any design
>> issues that would prevent strong robustness guarantees (without drastic
>> refactoring) in the future should be identified and fixed prior to release.
>> The documentation needs to reflect the actual guarantees and complexities of
>> every algorithm.
>>
>> - Concepts: more refinement needs to be done for the existing concepts. At
>> least 2 users claimed to not have been able to adapt their data structures
>> to the existing scheme. The library aims for defining the concepts and
>> interfaces for future geometry related work in Boost, so these use cases
>> need to be addressed. Users mentioned the missing concept inheritance. This
>> might be a good way to address the current problems of concepts being too
>> fine grained and too difficult to use. What needs to be done at minimum is
>> to enhance the flexibility of the concept mechanism enabling to adapt user
>> provided data structures more easily. The concepts need to be sound even in
>> the light of extensions.
>>
>> - Boolean operations: while the library provides a set of Boolean operations
>> those seem to be not complete and/or robust in terms of
>> clockwise/counterclockwise geometries, closed/open polygons. Robust Boolean
>> operations are a strong requirement, so this should be fixed as reported by
>> at least one reviewer.
>>
>> - Documentation: the documentation of the library is not complete and needs
>> additional effort. Using Doxygen alone as a documentation tool has its
>> (known) shortcomings when it comes to generic libraries. The authors already
>> mentioned to plan to switch to QuickBook after review allowing to have
>> better control over the generated docs.
>>
>> - Testing: several reviewers mentioned the need for a thorough testing
>> framework allowing the verification of the correctness of the algorithms in
>> a wide range of use cases. Different test strategies need to be employed,
>> such as high volume and random tests, known border case tests, tests using
>> different numeric precision types, etc.
>>
>> Minor (non-contingency) issues:
>>
>> - Names of used concepts: currently the library is using mainly terms as
>> established by the OpenGIS Consortium (OGC). This is misleading for users
>> coming from different (non-GIS) domains. It has been suggested to introduce
>> different namespaces for the different geometry domains (GIS, graphics, 3D,
>> etc.) allowing to use the expected terminology established in that
>> particular domain.
>>
>> - Name of the library: the name 'GGL - Generic Geometry Library' is
>> misleading as it is not a generic geometry library but a library using
>> generic programming techniques related to geometry. It has been suggested to
>> use the name Boost.Geometry instead. This is not a requirement imposed by
>> the review results, but I would like to suggest to the authors to consider
>> renaming.
>>
>> - Integration with Boost.Units has been suggested. The library does not need
>> to be completetly integrated with Boost.Units, although it appears to be
>> reasonable to deal with types as exposed by Boost.Units especially for
>> distance and area calculations.
>>
>> - Spatial data structures (such as spatial trees) have been mentioned to be
>> crucial for a geometry related library. While the library can't implement
>> all possible data structures in this field it can (and should) define
>> concepts and interfaces allowing future extensions while maintaining
>> interoperability.
>>
>> - In addition to that the reviewers made a lot of remarks related to
>> different smaller inconsistencies part of which already have been addressed
>> during the review. Barend has a full list of the remaining ones and promised
>> to address all of them.
>>
>> Last but not least I would like to encourage cooperation between the authors
>> of this library and the author of Boost.Polygon as both libraries have their
>> strength' worth combining. In an ideal world and at some point I would like
>> to see both libraries to be merged. But this is obviously not something to
>> expect really soon.
>>
>> At this point I would like to thank all who participated in the review and,
>> certainly, the authors for submitting this excellent library to Boost.
>>
>> Regards Hartmut
>> GGL Review Manager
>>
>> -------------------
>> Meet me at BoostConhttp://boostcon.com
>>
>>
>>
>> _______________________________________________
>> ggl mailing list
>> ggl_at_[hidden]
>> http://lists.osgeo.org/mailman/listinfo/ggl
>>
>>
>
>
> --
> Stephen Leary
>
> _______________________________________________
> ggl mailing list
> ggl_at_[hidden]
> http://lists.osgeo.org/mailman/listinfo/ggl
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20091128/9302cb65/attachment.html