Formal Review Request: Generic Geometry Library (GGL).
Hi, We would like to ask for a formal review for the Generic Geometry Library (GGL). The GGL defines concepts for geometries and implements some algorithms on such geometries. GGL contains a dimension-agnostic, coordinate-system-agnostic and scalable kernel, based on concepts, meta-functions and tag-dispatching. On top of that kernel, algorithms are built: area, length, perimeter, centroid, convex hull, intersection (clipping), within (point in polygon), distance, envelope (bounding box), simplify, transform, convert, and more. The library is also designed to support high precision arithmetic numbers, such as GMP. GGL contains instantiable geometry classes, but library users can also use their own. Using registration macros or traits classes their geometries can be adapted to fulfil the GGL-concepts. The GGL might be used in all domains where geometry plays a role: mapping and GIS, gaming, computer graphics and widgets, robotics, astronomy... The core is designed to be as generic as possible and support those domains. However, for now the development has been mostly GIS-oriented. We propose the extension model, the same way as GIL also applies it. So we are going to help to organize development of GGL extensions, where an extension is (mostly) something more specific to domains like mentioned above. The proposed GGL has seen four previews, many discussions and many changes in design and implementation, based on those discussions. The last preview was in February '09. Since then the design of the library is stable and the library contains a variety of coherent functionality. So we feel that the library is matured enough for formal review. Therefore, I would like to request a formal review and the library placed into the review queue. It is put into the Boost.Sandbox: https://svn.boost.org/svn/boost/sandbox/ggl/formal_review_request We have a review manager. Regards, Barend Gehrels, Bruno Lalande, Mateusz Loskot
Hi,
Therefore, I would like to request a formal review and the library placed into the review queue. It is put into the Boost.Sandbox: https://svn.boost.org/svn/boost/sandbox/ggl/formal_review_request
The documentation at http://geometrylibrary.geodan.nl/ is dated Feb 17 2009. Is there more up to date documentation at some other location? Regards, --> Mika Heiskanen
Hi Mika, Vicente, List, Mika Heiskanen wrote:
Hi,
Therefore, I would like to request a formal review and the library placed into the review queue. It is put into the Boost.Sandbox: https://svn.boost.org/svn/boost/sandbox/ggl/formal_review_request
The documentation at
http://geometrylibrary.geodan.nl/
is dated Feb 17 2009. Is there more up to date documentation at some other location?
It was not there yesterday, but it is there now: - http://geometrylibrary.geodan.nl/formal_review_request/ contains new documentation - Boost.Sandbox/ ... /libs/ggl/doc contains the same, but than at SVN - Boost.Sandbox/ ... /libs/ggl/example contains examples at SVN test will follow this week, as said. Regards, Barend
Hi, Barend Gehrels wrote:
- http://geometrylibrary.geodan.nl/formal_review_request/ contains new documentation - Boost.Sandbox/ ... /libs/ggl/doc contains the same, but than at SVN - Boost.Sandbox/ ... /libs/ggl/example contains examples at SVN
From the documentation it seems like buffering only works for positive offsets. Is the complement operation erosion also supported? Erosion is important when simplifying structures. It is common practice to first expand and then erode to get rid of minor details in shapes. Also, from the documentation it seems like Douglas-Peucker is the only available simplification algorithm. Do you have any plans to enlarge the set of available algorithms? DP is pretty much the worst algorithm we have available. Triangulation was not mentioned. However, triangulation is an effective tool for simplifying polygons, once you determine what your simplification criteria are. Do you have any plans to add triangulation as an elementary operation? Regards, --> Mika Heiskanen
Hi Mika,
From the documentation it seems like buffering only works for positive offsets. Is the complement operation erosion also supported? Erosion is important when simplifying structures. It is common practice to first expand and then erode to get rid of minor details in shapes.
The building blocks are there. But it is not implemented. Actually, buffering of polygons is also not part of this distribution.
Also, from the documentation it seems like Douglas-Peucker is the only available simplification algorithm. Do you have any plans to enlarge the set of available algorithms? DP is pretty much the worst algorithm we have available.
The Douglas-Peucker is implemented as a strategy, the default strategy, for the simplify algorithm. The design supports specifying other algorithms there, we could add them or library users could add them. At this moment DP is the only one. Most libraries have them as the default or the only one, by the way.
Triangulation was not mentioned. However, triangulation is an effective tool for simplifying polygons, once you determine what your simplification criteria are. Do you have any plans to add triangulation as an elementary operation?
Yes, there are plans, but indeed it is not implemented. All your questions focus on generalization/simplification, it is very interesting and, as a GIS-man, I'm sure willing to go further in that direction. Regards, Barend p.s. John, Vicente, thanks for the questions and clarifications, it makes the process very clear.
I just wanted to manifest my great interest in a Generic Geometry Library as part of boost. It could be very useful for us to be used in conjunction with Boost Graph and the Boost GIL to develop machine vision applications ( Pattern and object recognition ). Thanks a lot for your efforts. Peter
Hi, ----- Original Message ----- From: "Barend Gehrels" <barend@geodan.nl> To: <boost@lists.boost.org> Sent: Tuesday, October 13, 2009 6:25 PM Subject: Re: [boost] Formal Review Request: Generic Geometry Library (GGL).
Hi Mika, Vicente, List,
Mika Heiskanen wrote:
Hi,
Therefore, I would like to request a formal review and the library placed into the review queue. It is put into the Boost.Sandbox: https://svn.boost.org/svn/boost/sandbox/ggl/formal_review_request
The documentation at
http://geometrylibrary.geodan.nl/
is dated Feb 17 2009. Is there more up to date documentation at some other location?
It was not there yesterday, but it is there now:
- http://geometrylibrary.geodan.nl/formal_review_request/ contains new documentation - Boost.Sandbox/ ... /libs/ggl/doc contains the same, but than at SVN - Boost.Sandbox/ ... /libs/ggl/example contains examples at SVN
test will follow this week, as said.
Thanks Barend, this looks better ;-) Vicente
Hi, ----- Original Message ----- From: "Barend Gehrels" <barend@geodan.nl> To: <boost@lists.boost.org> Sent: Monday, October 12, 2009 3:03 PM Subject: [boost] Formal Review Request: Generic Geometry Library (GGL).
Hi,
We would like to ask for a formal review for the Generic Geometry Library (GGL).
The GGL defines concepts for geometries and implements some algorithms on such geometries.
GGL contains a dimension-agnostic, coordinate-system-agnostic and scalable kernel, based on concepts, meta-functions and tag-dispatching. On top of that kernel, algorithms are built: area, length, perimeter, centroid, convex hull, intersection (clipping), within (point in polygon), distance, envelope (bounding box), simplify, transform, convert, and more. The library is also designed to support high precision arithmetic numbers, such as GMP.
GGL contains instantiable geometry classes, but library users can also use their own. Using registration macros or traits classes their geometries can be adapted to fulfil the GGL-concepts.
The GGL might be used in all domains where geometry plays a role: mapping and GIS, gaming, computer graphics and widgets, robotics, astronomy... The core is designed to be as generic as possible and support those domains. However, for now the development has been mostly GIS-oriented.
We propose the extension model, the same way as GIL also applies it. So we are going to help to organize development of GGL extensions, where an extension is (mostly) something more specific to domains like mentioned above.
The proposed GGL has seen four previews, many discussions and many changes in design and implementation, based on those discussions. The last preview was in February '09. Since then the design of the library is stable and the library contains a variety of coherent functionality. So we feel that the library is matured enough for formal review.
Therefore, I would like to request a formal review and the library placed into the review queue. It is put into the Boost.Sandbox: https://svn.boost.org/svn/boost/sandbox/ggl/formal_review_request
I supose that the directory https://svn.boost.org/svn/boost/sandbox/ggl/formal_review_request/libs/ has not been commited. Best, Vicente
vicente.botet wrote:
Therefore, I would like to request a formal review and the library placed into the review queue. It is put into the Boost.Sandbox: https://svn.boost.org/svn/boost/sandbox/ggl/formal_review_request
I supose that the directory https://svn.boost.org/svn/boost/sandbox/ggl/formal_review_request/libs/ has not been commited.
The GGL is headers-only library, so the complete library is there. The libs is a placeholder where we are going to commit tests and a bunch of examples soon. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org
Hi, ----- Original Message ----- From: "Mateusz Loskot" <mateusz@loskot.net> To: <boost@lists.boost.org> Sent: Tuesday, October 13, 2009 1:17 AM Subject: Re: [boost] Formal Review Request: Generic Geometry Library (GGL).
vicente.botet wrote:
Therefore, I would like to request a formal review and the library placed into the review queue. It is put into the Boost.Sandbox: https://svn.boost.org/svn/boost/sandbox/ggl/formal_review_request
I supose that the directory https://svn.boost.org/svn/boost/sandbox/ggl/formal_review_request/libs/ has not been commited.
The GGL is headers-only library, so the complete library is there. The libs is a placeholder where we are going to commit tests and a bunch of examples soon.
When I see a library proposed for review I expect docs, tests and examples, so I can understand the library test it, and lear from the examples. It seems extrange to me you propose a library missing these important parts. It seems also extrange to me it has been accepted by the review manager and the review wizards. I supose all of you have deep reasons to do this way, Best, Vicente
Hi Vicente,
When I see a library proposed for review I expect docs, tests and examples, so I can understand the library test it, and lear from the examples. It seems extrange to me you propose a library missing these important parts. It seems also extrange to me it has been accepted by the review manager and the review wizards.
I supose all of you have deep reasons to do this way,
Sure, you are right, it should include everything. But note this 'request' is not yet the review, it is the request, and note that documentation, samples and tests were already available for four previews. Anyway, it will soon be complete. Because the library was included in the review schedule, we decided to publish the email yesterday to avoid confusions. We're building up the sandbox in three phases: - the source (yesterday) - examples and documentation (will be today) - tests (later this week) Sorry for the inconvenience. Regards, Barend
vicente.botet wrote:
Therefore, I would like to request a formal review and the library placed into the review queue. It is put into the Boost.Sandbox: https://svn.boost.org/svn/boost/sandbox/ggl/formal_review_request
I supose that the directory https://svn.boost.org/svn/boost/sandbox/ggl/formal_review_request/libs/ has not been commited.
The GGL is headers-only library, so the complete library is there. The libs is a placeholder where we are going to commit tests and a bunch of examples soon.
When I see a library proposed for review I expect docs, tests and examples, so I can understand the library test it, and lear from the examples. It seems extrange to me you propose a library missing these important parts. It seems also extrange to me it has been accepted by the review manager and the review wizards.
I supose all of you have deep reasons to do this way,
Everything can be looked at in the original SVN where GGL got developed. It will be added to the Boost sandbox SVN before the review (actually this week), so everybody will be able to see what's reviewed. Even more, this library has been presented for preliminary review on this list before and we've had lots of discussions already. FWIW, the documentation is still available at the old site if you can't wait until it's 'properly' added to Boost sandbox SVN. Based on this (and certainly rom looking at the library itself) I accepted to manage the library review. Moreover, Barends email was a request only, not the announcement of the actual review (which will happen in November, BTW). Regards Hartmut ------------------- Meet me at BoostCon http://boostcon.com
Hi,----- Original Message ----- From: "Hartmut Kaiser" <hartmut.kaiser@gmail.com> To: <boost@lists.boost.org> Sent: Tuesday, October 13, 2009 4:37 PM Subject: Re: [boost] Formal Review Request: Generic Geometry Library (GGL).
vicente.botet wrote:
Therefore, I would like to request a formal review and the library placed into the review queue. It is put into the Boost.Sandbox: https://svn.boost.org/svn/boost/sandbox/ggl/formal_review_request
I supose that the directory https://svn.boost.org/svn/boost/sandbox/ggl/formal_review_request/libs/ has not been commited.
The GGL is headers-only library, so the complete library is there. The libs is a placeholder where we are going to commit tests and a bunch of examples soon.
When I see a library proposed for review I expect docs, tests and examples, so I can understand the library test it, and lear from the examples. It seems extrange to me you propose a library missing these important parts. It seems also extrange to me it has been accepted by the review manager and the review wizards.
I supose all of you have deep reasons to do this way,
Everything can be looked at in the original SVN where GGL got developed. It will be added to the Boost sandbox SVN before the review (actually this week), so everybody will be able to see what's reviewed. Even more, this library has been presented for preliminary review on this list before and we've had lots of discussions already. FWIW, the documentation is still available at the old site if you can't wait until it's 'properly' added to Boost sandbox SVN.
Based on this (and certainly rom looking at the library itself) I accepted to manage the library review.
Moreover, Barends email was a request only, not the announcement of the actual review (which will happen in November, BTW).
I understand that this was the announcement of the review. It was just a Formal review request as the subject states. I understand also you and others know that GGL has a specific repository, but not necesarly other people. This shoudl explain you accepted to manage the review. The single error from my point of view was to give a web pointer with missing doc, test and examples while requesting a formal review. I wanted to say just that. I see now I should say nothing. Regards, Vicente
vicente.botet wrote:
Hi,
When I see a library proposed for review I expect docs, tests and examples, so I can understand the library test it, and lear from the examples. It seems extrange to me you propose a library missing these important parts. It seems also extrange to me it has been accepted by the review manager and the review wizards.
I supose all of you have deep reasons to do this way, Best, Vicente
Vicente, It is true that not everything for the library is currently in the sandbox. However, there is no requirement that the library is ever in the sandbox, so this is not a reason to deny a review. (If you look at the past history of reviews you will see that some libraries were never part of either the sandbox or the vault, but instead were hosted elsewhere. Remember that the sandbox and vault are for convenience, not required steps in development.) In the case of this library, because of the previous work in progress posts and requests for comment from Barend and collaborators we know that the missing pieces exist on previous forms and so don't have to worry that nothing is there. What are the actual requirements for a review request? There aren't any. A review request is a post by an author saying that there is a library they want reviewed. Though some authors share the work in progress before making the request, some others do not. You are confusing the request for a review from the author with the actual review of the library. For the actual review to happen there is a requirement that all the pieces be available to any interested reviewer (whether through the sandbox or some other source is not constrained), and the expectation that the review manager has looked at the library enough to believe that holding a review would not be a waste of the time of the other members of the list. The review wizards do not separately check this unless it is requested by the review manager (something that has not ever happened, to my knowledge). In this case, Hartmut has volunteered to manage the review. He is an experienced Boost developer and has managed high quality reviews in the past so the review wizards trust him to know if the library is ready for a review before asking for a date. That does not mean that anyone knows whether the library will pass the review. It just means that the library and its supporting files are complete enough and of high enough quality that the discussion will be valuable and there is a reasonable chance for passage. I hope that helps you understand the system more clearly. John Phillips Review Wizard
Hi, ----- Original Message ----- From: "John Phillips" <phillips@mps.ohio-state.edu> To: <boost@lists.boost.org> Sent: Tuesday, October 13, 2009 6:30 PM Subject: Re: [boost] Formal Review Request: Generic Geometry Library (GGL).
vicente.botet wrote:
Hi,
When I see a library proposed for review I expect docs, tests and examples, so I can understand the library test it, and lear from the examples. It seems extrange to me you propose a library missing these important parts. It seems also extrange to me it has been accepted by the review manager and the review wizards.
I supose all of you have deep reasons to do this way, Best, Vicente
Vicente,
It is true that not everything for the library is currently in the sandbox. However, there is no requirement that the library is ever in the sandbox, so this is not a reason to deny a review. (If you look at the past history of reviews you will see that some libraries were never part of either the sandbox or the vault, but instead were hosted elsewhere. Remember that the sandbox and vault are for convenience, not required steps in development.) In the case of this library, because of the previous work in progress posts and requests for comment from Barend and collaborators we know that the missing pieces exist on previous forms and so don't have to worry that nothing is there.
I understand completly your concern and want to recall however that I have never requested that the library should be on the sandbox. It was Barent that give the pointer to the saanbox for its library, not me.
What are the actual requirements for a review request? There aren't any. A review request is a post by an author saying that there is a library they want reviewed. Though some authors share the work in progress before making the request, some others do not.
It seems to me that the work to be reviewed must be signaled on the formal review request, isn't it?
You are confusing the request for a review from the author with the actual review of the library. For the actual review to happen there is a requirement that all the pieces be available to any interested reviewer (whether through the sandbox or some other source is not constrained), and the expectation that the review manager has looked at the library enough to believe that holding a review would not be a waste of the time of the other members of the list. The review wizards do not separately check this unless it is requested by the review manager (something that has not ever happened, to my knowledge).
No. I don't think I'm confusing anything. I was aware that this was just a Formal Review Request. As the review wizard adds the library on the review schedule with the pointer to the library to review, it seems to me that a short check on the contents of the given pointer should avoid posts from the Boost community requesting where the doc can be obtained and things like that.
In this case, Hartmut has volunteered to manage the review. He is an experienced Boost developer and has managed high quality reviews in the past so the review wizards trust him to know if the library is ready for a review before asking for a date. That does not mean that anyone knows whether the library will pass the review. It just means that the library and its supporting files are complete enough and of high enough quality that the discussion will be valuable and there is a reasonable chance for passage.
I have no doubt of the high quality of the work Harmunt does, much more the oposite I recognize it.
I hope that helps you understand the system more clearly.
I think I understand how the system works. And I know I have a lot of things to learm from this list, as for example, what is the good way to signal something is missing or wrong. I will try to do better next time :) I hope this will help you to understand what was my initial concern: Should we accept a formal review request when there is no doc, no test and no examples? Best regards, Vicente
vicente.botet wrote:
I think I understand how the system works. And I know I have a lot of things to learm from this list, as for example, what is the good way to signal something is missing or wrong. I will try to do better next time :)
I hope this will help you to understand what was my initial concern: Should we accept a formal review request when there is no doc, no test and no examples?
Best regards, Vicente
I think I would phrase things differently, to place the emphasis in a better place. Should we schedule a review for a library that is missing any of docs, tests, examples, ... . No, we should not. That is why the prospective review manager is expected to look at the library before scheduling the review. Not as a formal review itself, but to make sure that the library is in good enough shape to warrant a review at all. However, we don't have a good way to make that check before a library author requests a review on the developer list. In fact, in some cases the first anyone on the list hears about a library is the request for review. (This is not a process I suggest, nor is it usually successful, but it does happen.) There have been library submitters in the past that requested review for libraries that just weren't ready for what Boost expects. In some cases, interested review managers have worked with the submitter to help them understand the expectations and more thoroughly develop the library before asking for a review date. However, there is no history of the review wizards checking the library before allowing an author to request a review. To date, the role of the wizards has been more administration and advice than checking library details. Most of our review managers are quite good, and so there is no need for us to try and micromanage their work. We try to stay informed, and on the rare occasion that we need to step in on the details we do so, but that is thankfully rare. (All review managers deserve to be thanked for making it rare, by the way.) John
participants (7)
-
Barend Gehrels -
Hartmut Kaiser -
John Phillips -
Mateusz Loskot -
Mika Heiskanen -
Peter -
vicente.botet