Undefined symbols for architecture x86_64:
"___sincos_stret", referenced from:
RandomGenerator::createObject(int, int, double, double) in RandomGenerator.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Hi,

While compiling agains Spatial Index and using FFMPEG the compiler reports this error:
... error C2371: 'int8_t' : redefinition; different basic types ..

FFMPEG defines the signed types as:

   typedef signed __int8     int8_t;
   typedef signed __int16    int16_t;
   typedef signed __int32    int32_t;

While Tools.h uses:

  typedef __int8 int8_t;
  typedef __int16 int16_t;
  typedef __int32 int32_t;
  typedef __int64 int64_t;

Is signed missing?

All headers in spatialindex use the local include form:

#include "tools/Tools.h"

Point.h uses:

#include <spatialindex/tools/Tools.h>

When spatialindex is not installed in a standard location like /usr/local, this causes an error because the parent folder is not specified as a header folder.

Looks like paging in Index_Intersects_id is broken, I added it to Index_Intersects_obj but I didn't in the case of Ids. I will create a PR for this. I am going to break out paging as a utility function that I can then add to all of the intersect operations (nearest, linesegment etc).

Hello all,

I don't know if this is the right place to post this; but I am looking for a good example of how to bulk load points into a main-memory R-tree? Unfortunately the wiki only describes single point addition. Is there something I've missed in the documentation or the wiki? I appreciate your help.

Many thanks,
Giannis.

I am using libspatialindex in one of my projects. I am currently switching to MSVS2013.
As of now, I used MSVS2008 on the Windows side.
As it appears, it is impossible to use libspatialindex in combination with Boost (which is used in the same project) starting with MSVS2010.

Reason: Starting with MSVS2010, Microsoft defines its own stdint.h
header file. Boost starts pulling this header file as soon as it is available.

See: include\boost\config\compiler\visualc.hpp:

if _MSC_VER >= 1600

define BOOST_HAS_STDINT_H

endif

Libspatialindex has its own defines in Tools.h. These are created
independently of the Visual Studio version. There is just a simple
check for the MS OS.

As the defines created by Libspatialindex even differ from the MS
version of stdint.h, compile errors are inevitable:

\libspatialindex\include\spatialindex\tools/Tools.h(31): error C2371: 'int8_t' : redefinition; different basic types
\VC\include\stdint.h(8) : see declaration of 'int8_t'

Could you please adapt the check in Tools.h before setting own stdint defines.
Instead of just checking for Windows OS, there should be the same _MSC_VER check just like Boost does it.

It seems to me this function always returns true. Specifically, it looks like

if (
       (m_pLow[i] >= r.m_pLow[i] + std::numeric_limits<double>::epsilon() &&
        m_pLow[i] <= r.m_pLow[i] - std::numeric_limits<double>::epsilon()) ||
       (m_pHigh[i] >= r.m_pHigh[i] + std::numeric_limits<double>::epsilon() &&
        m_pHigh[i] <= r.m_pHigh[i] - std::numeric_limits<double>::epsilon()))
        return false;

requires the && and || to be swapped (since a >= b + e && a <= b - e should always be false)

The leaks program on OS X is claiming that IndexProperty_SetCustomStorageCallbacks is leaking. I'm assuming its this line:

https://github.com/libspatialindex/libspatialindex/blob/master/src/capi/sidx_api.cc#L3310

My guess is that when we destroy the index properties object we should be checking to see if that value is set to a pointer and free'ing it if so.

The "Libs" field should only contain libraries that programs must link to as well, when linking against libspatialindex and flags like -L/foo (which is the case here).

However, the current pkgconfig file inserts LDFLAGS in that field, which can lead to such undesired results:

pkg-config --libs libspatialindex

-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu

LDFLAGS should simply be removed from that spot

HI,

Im not expert with linux and c libraries, so probaly my description is incomplete or not very handful.
Anyway Im experiencing a problem with libspatialindex.so.3.0.0. Basically I have a plone (python) instance using a rtree library (https://github.com/Toblerity/Rtree). Now and then the instance dies with no clues and message. I've checked the dmesg report from linux and here is what I see:

[1476438.713131] traps: python[317] general protection ip:7fb04f5a2ff9 sp:7fb04a3440b0 error:0 in libspatialindex.so.3.0.0[7fb04f506000+b8000]
[1476763.870627] python[379]: segfault at 0 ip 00007f855e9ccaea sp 00007f85409640f8 error 4 in libc-2.19.so[7f855e944000+1bb000]
[1478334.385962] traps: python[1211] general protection ip:7ff88dbf5ff9 sp:7ff889198390 error:0 in libspatialindex.so.3.0.0[7ff88db59000+b8000]
[1526321.346560] traps: python[17381] general protection ip:7f33d0f48ff9 sp:7f33cc4eb390 error:0 in libspatialindex.so.3.0.0[7f33d0eac000+b8000]
[1527794.507131] traps: python[20645] general protection ip:7f8ccb8c6ff9 sp:7f8cc5766390 error:0 in libspatialindex.so.3.0.0[7f8ccb82a000+b8000]
[1528432.553798] python[20984]: segfault at 22 ip 00007f8f4de55ff2 sp 00007f8f404f6390 error 4 in libspatialindex.so.3.0.0[7f8f4ddb9000+b8000]
[1528892.762885] traps: python[21271] general protection ip:7f97170eeff2 sp:7f9711e90390 error:0 in libspatialindex.so.3.0.0[7f9717052000+b8000]
[1529146.029769] python[21388]: segfault at 0 ip 00007f29b5d25aea sp 00007f298bff9a88 error 4 in libc-2.19.so[7f29b5c9d000+1bb000]
[1529364.634798] python[21435]: segfault at 0 ip 00007fa394931aea sp 00007fa3780cc148 error 4 in libc-2.19.so[7fa3948a9000+1bb000]
[1529636.648433] python[21533]: segfault at 0 ip 00007f7c14cbaaea sp 00007f7bf37f6af8 error 4 in libc-2.19.so[7f7c14c32000+1bb000]

Im working on a linux instance (a VPS):

Linux 3.13.0-46-generic #79-Ubuntu SMP Tue Mar 10 20:06:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Any suggestion is very appreciated. Thank you in advance.

Let me first state that I'm quite unfamiliar with autoconf and friends... I've cloned the project (commit 9c989) and found there was no configure script. I had to run autoconf, automate and make copies of /usr/share/libtool/config/{config.guess,config.sub,ltmain.sh} in order to get a working configure script.

Please let me know if this is incorrect.

Do i understand it correctly that to update the data i need to first call DeleteData function of ISpatialIndex* tree object and afterwards call insertData again?

The codebase can be migrated to C++11, which will allow us to remove a number of homegrown tools/utilities that didn't really exist when libspatialindex was first developed. Some of the things we will attempt to refactor:

• remove Tools::SharedPtr in exchange for std::shared_ptr
• remove threading altogether
• Implement gtest for test runs

This is the easyest way to get spatialindez 1.7.1 to crosscompile using android ndk (tested with r6b)

--- a/configure
+++ b/configure
@@ -9846,8 +9846,17 @@ linux* | k*bsd*-gnu | kopensolaris*-gnu)
   version_type=linux
   need_lib_prefix=no
   need_version=no
-  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
-  soname_spec='${libname}${release}${shared_ext}$major'
+  case $host_os in
+  # This must be Linux Android ELF.
+  linux-android*)
+    library_names_spec='$libname${shared_ext}'
+    soname_spec='${libname}${shared_ext}'
+    ;;
+  *)  
+    library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
+    soname_spec='${libname}${release}${shared_ext}$major'
+    ;;
+  esac
   finish_cmds='PATH="\$PATH:/sbin" ldconfig -n $libdir'
   shlibpath_var=LD_LIBRARY_PATH
   shlibpath_overrides_runpath=no
@@ -13971,8 +13980,17 @@ linux* | k*bsd*-gnu | kopensolaris*-gnu)
   version_type=linux
   need_lib_prefix=no
   need_version=no
-  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
-  soname_spec='${libname}${release}${shared_ext}$major'
+  case $host_os in
+  # This must be Linux Android ELF.
+  linux-android*)
+    library_names_spec='$libname${shared_ext}'
+    soname_spec='${libname}${shared_ext}'
+    ;;
+  *)  
+    library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
+    soname_spec='${libname}${release}${shared_ext}$major'
+    ;;
+  esac
   finish_cmds='PATH="\$PATH:/sbin" ldconfig -n $libdir'
   shlibpath_var=LD_LIBRARY_PATH
   shlibpath_overrides_runpath=no
@@ -15699,7 +15717,7 @@ if test `eval echo '${'$as_ac_Header'}'` = yes; then
   cat >>confdefs.h <<_ACEOF
 #define `echo "HAVE_$ac_header" | $as_tr_cpp` 1
 _ACEOF
- LIBS="$LIBS -lpthread"
+# LIBS="$LIBS -lpthread"
 fi

 done

I have compiled those files in the docs, but it seems that only rough documentations are provided. I wonder if there is any specific documentation? Or the documentation work is just under construction?

Hi!
Can you provide msvs2013 32-bit build of libspatialindex too?

Extra null pointer checks are not needed in the destructor for the class "Index".

For background, we've been seeing an error in production when validating indexes on open. The only error message that's reported is:

https://github.com/libspatialindex/libspatialindex/blob/master/src/rtree/RTree.cc#L754

I dumped enough of a broken index to know that the bad node was at level 1 in a tree with a height of 4. I'm also pretty sure that this index was built with static input meaning that the failure to update the MBR in the parent is on the insert path.

Reading through the code many many times I finally realized that there's a broken assumption here:

https://github.com/libspatialindex/libspatialindex/blob/master/src/rtree/Index.cc#L294-L299

While its not specifically stated I'm fairly sure that the comment is relying on the assumption that adjustTree is only ever called for the case when we're expanding a node. Unfortunately that's not the case when we call it from Node::insertData on an R*-tree that is reinserting nodes to avoid a split.

During the reinsert we recalculate the child MBR and then call adjustTree. If any of the nodes removed happen to be part of the extreme of the child MBR then we're actually decreasing the size of the MBR which adjustTree does not take into account.

Unfortunately after hours of trying I'm unable to reproduce this in a test case. The conditions for this to happen are extremely finicky due to a combination of bugs and the complexity of R*-tree insertions. I also think that this requires that the node being reinserted has to be placed sufficiently far away from the original node or else the MBR accidentally gets updated during the reinsert. Granted its late andy brain hurts so I may be wrong.

Either way, I plan on writing a patch to force the readjustment when called from Node::insertData and deploying that to see if we end up with any more invalid indexes in production.

I'll update later if I find any broken indices after that patch has been on a cluster for awhile.

Apparently the recommendation is to vendor a copy of gtest which appears to have not been done.

https://code.google.com/p/googletest/wiki/FAQ#Why_is_it_not_recommended_to_install_a_pre-compiled_copy_of_Goog

Currently building with Cmake results in the following files and symlinks:

libspatialindex.so
libspatialindex.so.2.0.0

libspatialindex_c.so.
libspatialindex_c.so

Following the versions the Autotools produce, I created a patch: http://www.geofrogger.net/review/spatialindex-1.7.1-soname.patch

Applying it results in:

libspatialindex.so
libspatialindex.so.2
libspatialindex.so.2.0.0

libspatialindex_c.so
libspatialindex_c.so.2
libspatialindex_c.so.2.0.0

See here:

https://github.com/libspatialindex/libspatialindex/blob/master/src/spatialindex/Region.cc#L303-L307

The logic breaks down to:

(x1 >= y1 + z && x1 <= y1 - z) || (x2 >= y2 + z && x2 <= y2 - z)

First, z is greater (its std::numeric_limits<double>::epsilon()) so we don't have to worry about negations on the logical comparisons or that it might be zero.

Second, make the simplifying assumption that y1 == y2 == 0

Which reduces our logic to:

(x1 >= z && x1 <= -z) || (x2 >= z && x2 <= -z)

The only possible way that this logic could possibly evaluate to zero is if x1 == x2 == z == 0 which we know to be impossible because z is a positive constant.

So basically no matter what two region objects are given, the function touchesRegion returns true.

Thankfully though the only cases where its used (at least in RTree code) returning true doesn't appear that it would break anything. It just doesn't allow for some optimizations in avoiding unnecessary MBR recalculations.

I would personally fix this by making the affirmative case return true:

for (uint32_t i = 0; i < m_dimension; ++i)
{
    if((x1 >= y1 - z && x1 <= y1 + z) || (x2 >= y2 - z && x2 <= y2 - z)) {
        return true;
    }
}
return false;

spatialindex-src-1.8.5/src/rtree/PointerPoolNode.h:128]: (style) Unsigned variable 'c' can't be negative so it is unnecessary to test it.
spatialindex-src-1.8.5/src/mvrtree/PointerPoolNode.h:123]: (style) Unsigned variable 'c' can't be negative so it is unnecessary to test it.
spatialindex-src-1.8.5/src/tprtree/PointerPoolNode.h:124]: (style) Unsigned variable 'c' can't be negative so it is unnecessary to test it.
spatialindex-src-1.8.5/src/mvrtree/Node.cc:335]: (style) Unsigned variable 'index' can't be negative so it is unnecessary to test it.
spatialindex-src-1.8.5/src/rtree/Node.cc:315]: (style)
Unsigned variable 'index' can't be negative so it is unnecessary to test it.
spatialindex-src-1.8.5/src/tprtree/Node.cc:402]: (styl
e) Unsigned variable 'index' can't be negative so it is unnecessary to test it.

Installing libspatialindex-dev from the osgeo4w installer, creates the following includes folder layout:

• osgeo4w\include\spatialindex\
• - spatialindex\
• - - tools\
• - - capi\
• - - SpatialIndex.h
• - - etc.
• - Makefile.am

we have to spatialindex subfloders under the include directory

I am studying the test cases to understand if bulk loading a R* tree with Point data is possible.

The function RTree::createAndBulkLoadNewRTree takes a stream as one of the parameter which has a getNext function that return an IData. The RTree::Data constructor only supports creating an object with Region as one of the argument and not a Point.

Is bulk loading with Point data available?

Hello, can you add thread support for the windows? Now its only possible with the POSIX threads https://www.sourceware.org/pthreads-win32/. I want to use the libspatialindex as database and those semaphores can help me to keep the consistency of data stored when there will be many queries. I am not an expert on this so correct me if i am wrong about semaphores that with them i can use that library as a database,because they provide consistency of the data? You know,there will be many requests coming in and i think that these locks will prevent the data from being corrupted. I just heard about this at school, we didn´t go into much details :)

I couldn't find a way to query the min/max size in each dimension of an ISpatialIndex. Can this be added?

DEFAULT_LIB_SUBDIR is hard-coded to "lib". Various 64 bit systems store their 64 bit libs in lib64.

I made patch and tried with 32 and 64 bit Linux. It creates an explicit if-branch for APPLE. The else branch for other UNIXes appends ${LIB_SUFFIX} to "lib".

Adding "-DLIB_SUFFIX=64" to the cmake call allows for lib64.

http://www.geofrogger.net/review/spatialindex-1.7.0-64-bit.patch

Please update the postal address of the FSF in all files that include it.

The FSF moved from Temple Place to Franklin Street in 2005. Please find the current address under http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html

Please correct the permissions of all files in include/spatialindex/tools to 644.

@miklos1, I have multiple warnings after PR #82:

git\include\spatialindex\capi\Index.h(34): warning C4099: 'Index' : type name first seen using 'struct' now seen using 'class'
git\include\spatialindex\capi\sidx_config.h(104) : see declaration of 'Index'

In include\spatialindex\capi\Index.h (34):
class SIDX_DLL Index
and in include\spatialindex\capi\sidx_config.h (104):
typedef struct Index *IndexH;

with the help of SpatialIndex::IQueryStrategy, I can traverse the RTree in BFS manner. But how can I visit the tree in DFS manner? any advice?

This request is in regards to improving performance of segment intersection queries.

In the case where the objects stored in the spatialindex have bounds with dimensions that are an order of magnitude smaller than the segment we are intersecting with, the number of results is often MUCH greater than would be if the intersection were performed with a LineSegment-to-Region intersection (rather than the current Region-to-Region intersection).

I have implemented this LineSegment-to-Region intersection in a fork (https://github.com/chrisnatali/libspatialindex). This modification improved the performance for our Network Planning application by 10x where the stored objects were much smaller than the segments we were intersecting by.

If you think this modification is valuable to your code-base, I'll issue a Pull Request. If not, alternative solutions are welcome. Thanks.

when crosscompiling for android using ndk r6b I get:

../../include/spatialindex/tools/rand48.h:14:44: error: missing binary operator before token "("

replacing

# if !defined __cplusplus && __GNUC_PREREQ (3, 3)

with:

#ifndef GCC_VERSION
#define GCC_VERSION (__GNUC__ * 1000 + __GNUC_MINOR__)
#endif /* GCC_VERSION */
# if !defined __cplusplus && (GCC_VERSION >= 3003)

and

if defined __cplusplus &&(GCC_VERSION >= 2008)

makes compilation continue (to other errors)

see: http://www.unix.com/linux/76289-missing-binary-operator-before-token.html

As far as I know, I should install spatialindex using the following file.
libspatialindex-1.8.5-win-msvc-2013-x64.zip
The url is
http://libspatialindex.github.io/
It contains a bin, include, lib. But I don't know how to use it. Should I put it to somewhere?
I have installed python 3.4 and easy_install, pip.
I'll appreciate you all for helping me.
Thank you very much!

I found this while looking for a different bug:

https://github.com/libspatialindex/libspatialindex/blob/master/src/rtree/Index.cc#L343

The comment above that line says that the adjustment needs to be done if the new node isn't contained but bContained is calculated using n1 which is the old node. I haven't figured out a data set that will trigger a bug because each time n2 isn't contained it's still passed to insertData which calls insertEntry which adjusts the mbr. I'm not entirely sure if there's actually a possibility of miscalculating or if the logic is just incorrect and we don't need to look at bContained at all due to the n2 insert path.

Some parameters (like "${PROJECT_BINARY_DIR}/bin" and "${SIDX_HEADERS_DIR}/LineSegment.h") are passed to CMake commands in your build scripts without enclosing them by quotation marks. I see that these places will result in build difficulties if the contents of the used variables will contain special characters like spaces.

I would recommend to apply advices from a Wiki article.

Point.h has the following line:

include <spatialindex/tools/Tools.h>

As you seemingly switched to "libspatialindex" for your include directory, that doesn't work anymore.

Is it going to work if several thread query one index simultaneously?

I don't know what types file should be input and how to build a tprtree.
Who can tell me how to do it?
Thank you very much!

When compiling under android I get plenty of errors from tools/rand48.h about throwing different exceptions.

void srand48(long int) throw ()' throws different exceptions
/home/marco/dev/necessitas/android-9-standalonetoolchain/bin/../sysroot/usr/include/stdlib.h:111: error: from previous declaration 'void srand48(long int)'
../../include/spatialindex/tools/rand48.h:38: error: declaration of 'short unsigned int* seed48(short unsigned int*) throw ()' throws different exceptions
/home/marco/dev/necessitas/android-9-standalonetoolchain/bin/../sysroot/usr/include/stdlib.h:108: error: from previous declaration 'short unsigned int* seed48(short unsigned int*)'
../../include/spatialindex/tools/rand48.h:40: error: declaration of 'long int nrand48(short unsigned int*) throw ()' throws different exceptions
/home/marco/dev/necessitas/android-9-standalonetoolchain/bin/../sysroot/usr/include/stdlib.h:106: error: from previous declaration 'long int nrand48(short unsigned int*)'
../../include/spatialindex/tools/rand48.h:42: error: declaration of 'long int mrand48() throw ()' throws different exceptions
/home/marco/dev/necessitas/android-9-standalonetoolchain/bin/../sysroot/usr/include/stdlib.h:105: error: from previous declaration 'long int mrand48()'
../../include/spatialindex/tools/rand48.h:44: error: declaration of 'long int lrand48() throw ()' throws different exceptions
/home/marco/dev/necessitas/android-9-standalonetoolchain/bin/../sysroot/usr/include/stdlib.h:107: error: from previous declaration 'long int lrand48()'
../../include/spatialindex/tools/rand48.h:48: error: declaration of 'long int jrand48(short unsigned int*) throw ()' throws different exceptions
/home/marco/dev/necessitas/android-9-standalonetoolchain/bin/../sysroot/usr/include/stdlib.h:104: error: from previous declaration 'long int jrand48(short unsigned int*)'
../../include/spatialindex/tools/rand48.h:50: error: declaration of 'double erand48(short unsigned int*) throw ()' throws different exceptions
/home/marco/dev/necessitas/android-9-standalonetoolchain/bin/../sysroot/usr/include/stdlib.h:109: error: from previous declaration 'double erand48(short unsigned int*)'
../../include/spatialindex/tools/rand48.h:52: error: declaration of 'double drand48() throw ()' throws different exceptions
/home/marco/dev/necessitas/android-9-standalonetoolchain/bin/../sysroot/usr/include/stdlib.h:110: error: from previous declaration 'double drand48()'
make[2]: *** [RandomEvictionsBuffer.lo] Error 1

adding CXXFLAGS="-DHAVE_SRAND48=1" allows building but using the lib results in errors

Just tried to compile the current head and the make step failed. Any hints?

make
Making all in src
make[1]: Entering directory `/home/borgers/projects/libspatialindex/src'
Making all in storagemanager
make[2]: Entering directory `/home/borgers/projects/libspatialindex/src/storagemanager'
depbase=`echo Buffer.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
    /bin/bash ../../libtool --tag=CXX   --mode=compile g++ -DPACKAGE_NAME=\"spatialindex\" -DPACKAGE_TARNAME=\"spatialindex-src\" -DPACKAGE_VERSION=\"1.6.1\" -DPACKAGE_STRING=\"spatialindex\ 1.6.1\" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE=\"spatialindex-src\" -DVERSION=\"1.6.1\" -DHAVE_FCNTL_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_STDINT_H=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_BZERO=1 -DHAVE_MEMSET=1 -DHAVE_MEMCPY=1 -DHAVE_BCOPY=1 -I. -I../../include     -Wall -Wno-long-long -pedantic -std=c++98  -O2 -DNDEBUG -MT Buffer.lo -MD -MP -MF $depbase.Tpo -c -o Buffer.lo Buffer.cc &&\
    mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  g++ -DPACKAGE_NAME=\"spatialindex\" -DPACKAGE_TARNAME=\"spatialindex-src\" -DPACKAGE_VERSION=\"1.6.1\" "-DPACKAGE_STRING=\"spatialindex 1.6.1\"" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE=\"spatialindex-src\" -DVERSION=\"1.6.1\" -DHAVE_FCNTL_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_STDINT_H=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_BZERO=1 -DHAVE_MEMSET=1 -DHAVE_MEMCPY=1 -DHAVE_BCOPY=1 -I. -I../../include -Wall -Wno-long-long -pedantic -std=c++98 -O2 -DNDEBUG -MT Buffer.lo -MD -MP -MF .deps/Buffer.Tpo -c Buffer.cc  -fPIC -DPIC -o .libs/Buffer.o
libtool: compile:  g++ -DPACKAGE_NAME=\"spatialindex\" -DPACKAGE_TARNAME=\"spatialindex-src\" -DPACKAGE_VERSION=\"1.6.1\" "-DPACKAGE_STRING=\"spatialindex 1.6.1\"" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE=\"spatialindex-src\" -DVERSION=\"1.6.1\" -DHAVE_FCNTL_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_STDINT_H=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_BZERO=1 -DHAVE_MEMSET=1 -DHAVE_MEMCPY=1 -DHAVE_BCOPY=1 -I. -I../../include -Wall -Wno-long-long -pedantic -std=c++98 -O2 -DNDEBUG -MT Buffer.lo -MD -MP -MF .deps/Buffer.Tpo -c Buffer.cc -o Buffer.o >/dev/null 2>&1
depbase=`echo DiskStorageManager.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
    /bin/bash ../../libtool --tag=CXX   --mode=compile g++ -DPACKAGE_NAME=\"spatialindex\" -DPACKAGE_TARNAME=\"spatialindex-src\" -DPACKAGE_VERSION=\"1.6.1\" -DPACKAGE_STRING=\"spatialindex\ 1.6.1\" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE=\"spatialindex-src\" -DVERSION=\"1.6.1\" -DHAVE_FCNTL_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_STDINT_H=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_BZERO=1 -DHAVE_MEMSET=1 -DHAVE_MEMCPY=1 -DHAVE_BCOPY=1 -I. -I../../include     -Wall -Wno-long-long -pedantic -std=c++98  -O2 -DNDEBUG -MT DiskStorageManager.lo -MD -MP -MF $depbase.Tpo -c -o DiskStorageManager.lo DiskStorageManager.cc &&\
    mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  g++ -DPACKAGE_NAME=\"spatialindex\" -DPACKAGE_TARNAME=\"spatialindex-src\" -DPACKAGE_VERSION=\"1.6.1\" "-DPACKAGE_STRING=\"spatialindex 1.6.1\"" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE=\"spatialindex-src\" -DVERSION=\"1.6.1\" -DHAVE_FCNTL_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_STDINT_H=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_BZERO=1 -DHAVE_MEMSET=1 -DHAVE_MEMCPY=1 -DHAVE_BCOPY=1 -I. -I../../include -Wall -Wno-long-long -pedantic -std=c++98 -O2 -DNDEBUG -MT DiskStorageManager.lo -MD -MP -MF .deps/DiskStorageManager.Tpo -c DiskStorageManager.cc  -fPIC -DPIC -o .libs/DiskStorageManager.o
libtool: compile:  g++ -DPACKAGE_NAME=\"spatialindex\" -DPACKAGE_TARNAME=\"spatialindex-src\" -DPACKAGE_VERSION=\"1.6.1\" "-DPACKAGE_STRING=\"spatialindex 1.6.1\"" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE=\"spatialindex-src\" -DVERSION=\"1.6.1\" -DHAVE_FCNTL_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_STDINT_H=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_BZERO=1 -DHAVE_MEMSET=1 -DHAVE_MEMCPY=1 -DHAVE_BCOPY=1 -I. -I../../include -Wall -Wno-long-long -pedantic -std=c++98 -O2 -DNDEBUG -MT DiskStorageManager.lo -MD -MP -MF .deps/DiskStorageManager.Tpo -c DiskStorageManager.cc -o DiskStorageManager.o >/dev/null 2>&1
depbase=`echo MemoryStorageManager.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
    /bin/bash ../../libtool --tag=CXX   --mode=compile g++ -DPACKAGE_NAME=\"spatialindex\" -DPACKAGE_TARNAME=\"spatialindex-src\" -DPACKAGE_VERSION=\"1.6.1\" -DPACKAGE_STRING=\"spatialindex\ 1.6.1\" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE=\"spatialindex-src\" -DVERSION=\"1.6.1\" -DHAVE_FCNTL_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_STDINT_H=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_BZERO=1 -DHAVE_MEMSET=1 -DHAVE_MEMCPY=1 -DHAVE_BCOPY=1 -I. -I../../include     -Wall -Wno-long-long -pedantic -std=c++98  -O2 -DNDEBUG -MT MemoryStorageManager.lo -MD -MP -MF $depbase.Tpo -c -o MemoryStorageManager.lo MemoryStorageManager.cc &&\
    mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  g++ -DPACKAGE_NAME=\"spatialindex\" -DPACKAGE_TARNAME=\"spatialindex-src\" -DPACKAGE_VERSION=\"1.6.1\" "-DPACKAGE_STRING=\"spatialindex 1.6.1\"" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE=\"spatialindex-src\" -DVERSION=\"1.6.1\" -DHAVE_FCNTL_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_STDINT_H=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_BZERO=1 -DHAVE_MEMSET=1 -DHAVE_MEMCPY=1 -DHAVE_BCOPY=1 -I. -I../../include -Wall -Wno-long-long -pedantic -std=c++98 -O2 -DNDEBUG -MT MemoryStorageManager.lo -MD -MP -MF .deps/MemoryStorageManager.Tpo -c MemoryStorageManager.cc  -fPIC -DPIC -o .libs/MemoryStorageManager.o
libtool: compile:  g++ -DPACKAGE_NAME=\"spatialindex\" -DPACKAGE_TARNAME=\"spatialindex-src\" -DPACKAGE_VERSION=\"1.6.1\" "-DPACKAGE_STRING=\"spatialindex 1.6.1\"" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE=\"spatialindex-src\" -DVERSION=\"1.6.1\" -DHAVE_FCNTL_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_STDINT_H=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_BZERO=1 -DHAVE_MEMSET=1 -DHAVE_MEMCPY=1 -DHAVE_BCOPY=1 -I. -I../../include -Wall -Wno-long-long -pedantic -std=c++98 -O2 -DNDEBUG -MT MemoryStorageManager.lo -MD -MP -MF .deps/MemoryStorageManager.Tpo -c MemoryStorageManager.cc -o MemoryStorageManager.o >/dev/null 2>&1
depbase=`echo RandomEvictionsBuffer.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
    /bin/bash ../../libtool --tag=CXX   --mode=compile g++ -DPACKAGE_NAME=\"spatialindex\" -DPACKAGE_TARNAME=\"spatialindex-src\" -DPACKAGE_VERSION=\"1.6.1\" -DPACKAGE_STRING=\"spatialindex\ 1.6.1\" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE=\"spatialindex-src\" -DVERSION=\"1.6.1\" -DHAVE_FCNTL_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_STDINT_H=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_BZERO=1 -DHAVE_MEMSET=1 -DHAVE_MEMCPY=1 -DHAVE_BCOPY=1 -I. -I../../include     -Wall -Wno-long-long -pedantic -std=c++98  -O2 -DNDEBUG -MT RandomEvictionsBuffer.lo -MD -MP -MF $depbase.Tpo -c -o RandomEvictionsBuffer.lo RandomEvictionsBuffer.cc &&\
    mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  g++ -DPACKAGE_NAME=\"spatialindex\" -DPACKAGE_TARNAME=\"spatialindex-src\" -DPACKAGE_VERSION=\"1.6.1\" "-DPACKAGE_STRING=\"spatialindex 1.6.1\"" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE=\"spatialindex-src\" -DVERSION=\"1.6.1\" -DHAVE_FCNTL_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_STDINT_H=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_BZERO=1 -DHAVE_MEMSET=1 -DHAVE_MEMCPY=1 -DHAVE_BCOPY=1 -I. -I../../include -Wall -Wno-long-long -pedantic -std=c++98 -O2 -DNDEBUG -MT RandomEvictionsBuffer.lo -MD -MP -MF .deps/RandomEvictionsBuffer.Tpo -c RandomEvictionsBuffer.cc  -fPIC -DPIC -o .libs/RandomEvictionsBuffer.o
In file included from RandomEvictionsBuffer.cc:25:0:
../../include/tools/rand48.h:3:30: error: declaration of ‘void srand48(long int)’ throws different exceptions
/usr/include/stdlib.h:409:13: error: from previous declaration ‘void srand48(long int) throw ()’
../../include/tools/rand48.h:4:54: error: declaration of ‘short unsigned int* seed48(short unsigned int*)’ throws different exceptions
/usr/include/stdlib.h:410:28: error: from previous declaration ‘short unsigned int* seed48(short unsigned int*) throw ()’
../../include/tools/rand48.h:5:44: error: declaration of ‘long int nrand48(short unsigned int*)’ throws different exceptions
/usr/include/stdlib.h:400:17: error: from previous declaration ‘long int nrand48(short unsigned int*) throw ()’
../../include/tools/rand48.h:6:25: error: declaration of ‘long int mrand48()’ throws different exceptions
/usr/include/stdlib.h:404:17: error: from previous declaration ‘long int mrand48() throw ()’
../../include/tools/rand48.h:7:25: error: declaration of ‘long int lrand48()’ throws different exceptions
/usr/include/stdlib.h:399:17: error: from previous declaration ‘long int lrand48() throw ()’
../../include/tools/rand48.h:8:40: error: declaration of ‘void lcong48(short unsigned int*)’ throws different exceptions
/usr/include/stdlib.h:412:13: error: from previous declaration ‘void lcong48(short unsigned int*) throw ()’
../../include/tools/rand48.h:9:44: error: declaration of ‘long int jrand48(short unsigned int*)’ throws different exceptions
/usr/include/stdlib.h:405:17: error: from previous declaration ‘long int jrand48(short unsigned int*) throw ()’
../../include/tools/rand48.h:10:46: error: declaration of ‘double erand48(short unsigned int*)’ throws different exceptions
/usr/include/stdlib.h:396:15: error: from previous declaration ‘double erand48(short unsigned int*) throw ()’
../../include/tools/rand48.h:11:27: error: declaration of ‘double drand48()’ throws different exceptions
/usr/include/stdlib.h:395:15: error: from previous declaration ‘double drand48() throw ()’
make[2]: *** [RandomEvictionsBuffer.lo] Error 1
make[2]: Leaving directory `/home/borgers/projects/libspatialindex/src/storagemanager'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/borgers/projects/libspatialindex/src'
make: *** [all-recursive] Error 1

this is convient for users to flush data to disk. After all, the destroy construct function is not so convient to use.

There seems to be a consistency issue between using uint64_t and int64_t, I have changed the CAPI for result offset and count to be int64_t but then these get used against uint64_t. Not a large issue in my case, but I can take this work on if we have a consensus on which one (I think uint64_t).

Hi. I've been using the branch "master" on my project and it worked fine up to now doing only one indexing and then multiple loadings but now I need to index more points dynamically and guarantee that it's saved on disk. I'm trying to use the "flush" function of the RTree with no success, if I print (<<) the tree before flushing, the statistics are fine, but after that, utilization is "0%" and the number of nodes in level is a bizarre number. I could not make a program simple enough to reproduce the problem exactly but the following code shows that apparently there's no data on the tree after the flush.

#include <spatialindex/SpatialIndex.h>
#include <iostream>
using namespace std;

using namespace SpatialIndex;
using namespace SpatialIndex::RTree;
using namespace SpatialIndex::StorageManager;

int main(){
        string name("test");
    auto disk = createNewDiskStorageManager(name, 4096);
    id_type id;
    auto tree = createNewRTree(*disk, 0.7, 1000000, 100, 2,
            RTree::RTreeVariant::RV_RSTAR, id);
    for (int i = 0; i < 130; i++) {
        double pt[] = { i, i };
        SpatialIndex::IShape* shape = new SpatialIndex::Point(pt, 2);
        tree->insertData(0, 0, *shape, 0);
    }

    cout << "flush" << endl;
    cout << *tree << endl;
    disk->flush();
    tree->flush();
    cout << "after flush" << endl;
    cout << *tree << endl;
}

The output here is:

flush
Dimension: 2
Fill factor: 0.7
Index capacity: 1000000
Leaf capacity: 100
Tight MBRs: enabled
Near minimum overlap factor: 32
Reinsert factor: 0.3
Split distribution factor: 0.4
Utilization: 65%
Reads: 188
Writes: 162
Hits: 0
Misses: 0
Tree height: 2
Number of data: 130
Number of nodes: 3
Level 0 pages: 2
Level 1 pages: 1
Splits: 1
Adjustments: 29
Query results: 0

after flush
Dimension: 2
Fill factor: 0.7
Index capacity: 1000000
Leaf capacity: 100
Tight MBRs: enabled
Near minimum overlap factor: 32
Reinsert factor: 0.3
Split distribution factor: 0.4

And here is an output from my application:

flush
Dimension: 2
Fill factor: 0.7
Index capacity: 1000000
Leaf capacity: 100
Tight MBRs: enabled
Near minimum overlap factor: 32
Reinsert factor: 0.3
Split distribution factor: 0.4
Utilization: 29%
Reads: 30
Writes: 30
Hits: 0
Misses: 0
Tree height: 1
Number of data: 29
Number of nodes: 1
Level 0 pages: 1
Splits: 0
Adjustments: 0
Query results: 0

after flush
Dimension: 2
Fill factor: 0.7
Index capacity: 1000000
Leaf capacity: 100
Tight MBRs: enabled
Near minimum overlap factor: 32
Reinsert factor: 0.3
Split distribution factor: 0.4
Utilization: 0%
Reads: 30
Writes: 30
Hits: 0
Misses: 0
Tree height: 1
Number of data: 29
Number of nodes: 1
Level 0 pages: 42195368
Splits: 0
Adjustments: 0
Query results: 0

I want to perform incremental NN Search on RTree towards different queries. To improve the efficiency, I decide to perform the search simultaneously with the help of threads. Therefore I rewrite the nearestNeighborQuery procedure and add a lock in the while loop. In the beginning, the program is executed quite well. But unexpectedly, after executing the program several times, the data file is corrupted because the exception ‘SpatialIndex::DiskStorageManager: Corrupted data file’ is threw out.

I don't know why just reading the tree data and performing some search will corrupt the data file. Any idea to explain this and solve the program? Thanks!

Would you like to replace any double quotes by angle brackets around file names for include statements?

Would you like to wrap any pointer data members with the template class "std::unique_ptr"?

Update candidates:

• Index
• Node

the test code is generated inside the cmake directory (e.g Release), however they are not copied to test directory.

libspatialindex-1.8.5-win-msvc-2013-x64.zip contains bin, include, lib directories and libspatialindex-1.8.5-1-src.tar.bz2 archive, which contains bin, lib, include directories too, not source.

I'm trying to use the C API, but the header files seem to (indirectly) pull in C++ headers which the C compiler cannot handle. For example, compiling:

#include <spatialindex/capi/sidx_api.h>

fails with:

In file included from /usr/include/spatialindex/SpatialIndex.h:30:0,
                 from /usr/include/spatialindex/capi/sidx_config.h:56,
                 from /usr/include/spatialindex/capi/sidx_api.h:34,
                 from main.c:1:
/usr/include/spatialindex/tools/Tools.h:59:20: fatal error: iostream: No such file or directory
 #include <iostream>
                    ^
compilation terminated.