This is not really a bug report or direct feature request, rather a relatively advanced question on the implementation of the STRTree / ctypes.
(and since I don't know of a good mailing list to ask such questions, opening an issue here. But if that is not appropriate, feel free to close).

I am interested in having a STRTree version that returns the index of the geometries instead of the geometry itself when querying the tree.

Looking at the implementation of the STRTree, I would have thought I could achieve that by using a custom version of it, with the following minimal change (so storing the integer index in the tree instead of the geometry):

diff --git a/shapely/strtree.py b/shapely/strtree.py
index 121b740..497c7ca 100644
--- a/shapely/strtree.py
+++ b/shapely/strtree.py
@@ -36,8 +36,8 @@ class STRtree:
         self._n_geoms = len(geoms)
         # GEOS STRtree capacity has to be > 1
         self._tree_handle = lgeos.GEOSSTRtree_create(max(2, len(geoms)))
-        for geom in geoms:
-            lgeos.GEOSSTRtree_insert(self._tree_handle, geom._geom, ctypes.py_object(geom))
+        for i, geom in enumerate(geoms):
+            lgeos.GEOSSTRtree_insert(self._tree_handle, geom._geom, ctypes.py_object(i))
 
         # Keep references to geoms.
         self._geoms = list(geoms)

This seems to work, however sometimes one of the returned integers when querying is a faulty one (big random number that does not fit in the range of number of geoms), and this seems to happen somewhat randomly (not on each run, and for some of the geometries)

Example notebook illustrating it: http://nbviewer.ipython.org/1ed26fda7fd0abf50d152b754f82f5fb

Does somebody have any idea what would be wrong about the above modification of the STRTree code?