On Jul 14, 2011, at 2:30 PM, Sean Gillies <[email protected]> wrote:
> 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? We should rip the Bandaid off earlier rather than later. We should ask on the libspatialindex list if anyone is even using the C API other than us to hear what the impact might be. If no one speaks up, I'll just fix it. Howard _______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
