I can confirm Rtree works as expected :)
>>> import rtree >>> tree = rtree.Rtree() >>> tree.add(-1, (0,0)) >>> list(tree.intersection((0, 0))) [-1L] >>> bounds = [0,0,1,1] >>> tree.add(-1288508995,bounds) >>> list(tree.intersection(bounds)) [-1L, -1288508995L] I can also confirm that the new version or Rtree works fine with the implementation of collective.geo.index (all items are shown, the formerly 'missing' items too) without rebuilding the catalog. Also no incidents to report when i reindex the catalog- everything works fine :) On Sat, Jul 16, 2011 at 2:15 AM, Sean Gillies <[email protected]> wrote: > On Thu, Jul 14, 2011 at 2:59 PM, Howard Butler <[email protected]> wrote: >> >> >> 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 > > I can confirm that with commits > > https://github.com/Rtree/Rtree/commit/415ab33f26c1e2960d5c58b9471e0186dd102a4e > https://github.com/libspatialindex/libspatialindex/commit/787128ab5c7b00203efc10a08138ae0a39ce99ec > > the Rtree tests pass and negative index values are working: > >>> from rtree import Rtree >>>> tree = Rtree() >>>> tree.add(-1, (0,0)) > x3b2e68> >>>> list(tree.intersection((0, 0))) > [-1L] > > Christian, can you try it out? > > -- > Sean > _______________________________________________ > Community mailing list > [email protected] > http://lists.gispython.org/mailman/listinfo/community > -- Best Regards, Christian Ledermann Nairobi - Kenya Mobile : +254 702978914 <*)))>{ If you save the living environment, the biodiversity that we have left, you will also automatically save the physical environment, too. But If you only save the physical environment, you will ultimately lose both. 1) Don’t drive species to extinction 2) Don’t destroy a habitat that species rely on. 3) Don’t change the climate in ways that will result in the above. }<(((*> _______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
