On Wed, Jul 13, 2011 at 9:42 AM, Howard Butler <[email protected]> wrote: > > On Jul 13, 2011, at 10:34 AM, Sean Gillies wrote: > >> On Wed, Jul 13, 2011 at 12:09 AM, Christian Ledermann >> <[email protected]> wrote: >>> I discovered a bug in rtree: >>> >>>>>> from rtree import Rtree >>>>>> tree = Rtree() >>>>>> bounds = [0,0,1,1] >>>>>> tree.add(1,bounds) >>>>>> list(tree.intersection(bounds)) >>> [1L] >>>>>> tree.add(-1288508995,bounds) >>>>>> list(tree.intersection(bounds)) >>> [1L, 18446744072421042621L] >>>>>> >>> >>> >>> >> >> Hi Christian, >> >> Libspatialindex uses unsigned longs and we've failed to document this >> properly. If you are hashing objects to make integer ids, you'll need >> to shift the values to be > 0. >> > > Sean, > > This is my mistake in the libspatialindex API. > > I see this in the SpatialIndex.h header: > > typedef int64_t id_type; > > but for some reason, I used uint64_t's for the ids and the compiler didn't > warn us about that. > > /me wonders how to/if to fix this gracefully. >
Let's do fix this. Rtree users wouldn't notice the difference. How many other users of the C API are there? I think I've seen more questions about the C++ classes. Could we make a new C interface with uint64_t shims for backwards compatibility, or is that too ugly? -- Sean _______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
