Howard Butler wrote: > On Aug 22, 2008, at 4:10 PM, Sean Gillies wrote: > >> Jaakko Salli wrote: >>> Sean Gillies wrote: >>>> Hi all, >>>> >>>> If I remember correctly, the blocker for Rtree 1.0 >>>> >>>> http://trac.gispython.org/lab/milestone/Rtree%201.0 >>>> >>>> is a unwritten want to have the Spatialindex library build on >>>> Windows. >>>> >>> What problems exactly did you have building spatialindex on Windows? >>> >>> Regards, >>> Jaakko >> Hi Jaakko, >> >> I haven't had any problems, myself, but then I'm not a Windows user ;) >> Do you have a DLL that works? If so, could I persuade you to make an >> Rtree bdist_winist [1] for us? >> >> Back to the 1.0 idea here ... Howard expressed a desire to switch >> Rtree >> over to using ctypes before 1.0. I'd rather just get it out there as >> it >> is since it's functionally complete, and perhaps switch to ctypes in a >> future milestone. Howard, how about we resolve this as you do in >> MapServer? That is, a -1 vote on pushing Rtree forward to 1.0 as it is >> carries with it the obligation to take the lead on a ctypes >> implementation. > > > I won't veto it if a veto takes on that responsibility. I don't think > the current Rtree should be called 1.0, but I'm not too picky on > names. Here's some of the reasons why I don't think we're at 1.0 yet: > > - We don't work on windows for file-based index storage (this is > spatialindex's fault of course).
It doesn't? I don't see any mention of that at http://trac.gispython.org/spatialindex/query?status=new&status=assigned&status=reopened&status=closed&order=priority I did find a mention here http://lists.gispython.org/pipermail/spatialindex/2008-January/000012.html I'm not sure who will *ever* be motivated to fix this. > - We only support an extremely simple subset of what spatialindex > supports, with very little configuration for a user who knows their > way around r*trees. Performance/memory issues that we might see from > Python can easily be blamed on our limited configuration ability > rather than the spatialindex library. Sure, but I think what we do provide is good enough for a 1.0. > - The C/C++ interface between spatialindex and the Python Rtree code > is less than ideal, and I don't think it is sustainable for long term > development if the goal above is also a goal of the project. > Maybe. I suspect that there will never be many people motivated to do anything about configuration, C or ctypes. I think it's you and me no matter what. For example: Shapely uses ctypes, but I can't find more than 1 instance of a patch involving ctypes. We've already received that many patches for Rtree's C/C++ interface. Within these projects there is no demonstrated win (yet) for ctypes. > I do desire this stuff to be improved, but I have no time/money/client/ > business case to drive it forward. If we want to slap a 1.0 on what > we have and call the next 2.0, that's fine with me too. Whatever we > call it, it's not *done* in my mind. > > Howard I don't think it's done either. But it is satisfying its main customer, zgeo.spatialindex, and meeting my initial design goals. Sean _______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
