Subject: [boost] Boost.Geometry and extensions (was: GGL review (JTF))
From: Barend Gehrels (barend_at_[hidden])
Date: 2009-12-04 14:29:14
Jonathan Franklin wrote:
>>> However, it is a shame that the library lacks a first-class spatial
>>> index capability in it's present state (e.g. what is up for review). ...
>> It is available as an extension, the reasons for non-inclusion were:
>> - we want to improve performance
>> - we want to enhance the interface
> So will it be moved *into* the library-proper at some point, or will
> it always remain an extension?
We have never clarified this point until now, and herewith we want to,
in the broader context of extensions (more reviewers mentioned extensions).
Theoretically, options for extensions are:
1) no review at all
2) review within osgeo.org/ggl
3) fast track review within Boost
4) formal review within Boost
a) smaller functionality, built in the library (so, without being an
b) functionality, moving from "extension" to "kernel"
c) functionality, staying as an extension forever (included in Boost
d) functionality, staying as an extension forever (not included in Boost
Probably every Boost library contains things as a). Those can come
without (formal) review, so 1) will do. Algorithms fitting in the design
and adding similar functionality are (probably) accepted in all libraries.
However, there are, and might be more, extensions which are larger and
have their own design, at least partly. The spatial index is such an
extension. Some extensions will be written by us (submitters of GGL),
other extensions might be written by programmers from the Boost
community or from the GGL-mailing-list.
For larger parts, as extensions are, so for b) and c), we propose to
first do a review within the GGL-mailing-list. If we from that list
think that the quality is good enough and that it is useful for
inclusion within Boost, we want to propose a fast track review within
Boost. Boost formally has that fast track review process; it is not used
a lot (afaik), but it makes sense to use it for extensions.
Spatial indexes are an example of b), because they are developed as an
extension, but algorithms within the kernel might profit from it. So
they then have to be moved somewhere inside the kernel.
Projections are probably an example of c). They will probably always be
extensions, but because of the worldwide usage of projections within GIS
applications, it might make sense to have them within Boost as well. But
that is then for a fast track review process to decide, of course.
There are more libraries having extensions within Boost. GIL is
mentioned before and has extensions distributed within Boost (so maybe
like our c) ) and not distributed (maybe d), don't know) but mentioned
in the documentation and examples. And I noticed that GIL.IO is on the
review schedule. So our proposal above might be conform conventions and
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk