On Wed, Jul 13, 2011 at 6:42 PM, Howard Butler <[email protected]> wrote:
>
> On Jul 13, 2011, at 10:34 AM, Sean Gillies wrote:
>
>> 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.
>
>
>
>> In Vaytrou, I maintain a pair of OI and IO BTrees to map objects to a
>> positive integer id following the example of zope.intid.
I agree that this can be 'worked around' at the application level (for
the short term) but this is not how it should be.
Remember the olden days when bugs became features like the A20 gate? I
don't want to go up this road, I've been there before
I REALLY want to see this fixed upstream (in Midterm in Rtree and in
the long term in spatial index)
I agree with Howard (assuming i interpret him right) that an API
change of spatialindex should be delayed to the next major version
which has API changes.
--
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
