Boost logo

Boost :

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
3) fast track review within Boost
4) formal review within Boost

And, orthogonally:
a) smaller functionality, built in the library (so, without being an
extension first)
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

Regards, Barend

Boost list run by bdawes at, gregod at, cpdaniel at, john at