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