[boost] Boost.Geometry and extensions (was: GGL review (JTF))

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

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 
distribution)
d) functionality, staying as an extension forever (not included in Boost 
distribution)

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 
expectations.

Regards, Barend