|
Boost : |
Subject: Re: [boost] Another GGL review
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-11-17 16:29:36
Jonathan Franklin wrote:
> On Tue, Nov 17, 2009 at 12:17 PM, Simonson, Lucanus J
> <lucanus.j.simonson_at_[hidden]> wrote:
>> Jonathan Franklin wrote:
>>> For the purposes of my own review, I'm trying to decide whether I
>>> think the library should be accepted without a spatial index. Would
>>> anyone like to sway my opinion one way or the other?
>>> :-)
>>
>> Personally I don't think that is a reasonable condition. If I were
>> managing the review I would discount such an objection as
>> unreasonable.
>
> So, if you're saying that my own personal needs in a library are much
> less important that the community's needs, then I totally agree.
> :-)
>
> Clearly, there has to be some minimum level of functionality for a
> library to be generally useful. I'm trying to convince myself that
> GGL will be useful to me without a spatial index, and wondering if
> others need spatial indexing as much as I do.
>
> Luke, you evidently don't need spatial indexing, so that's one good
> datum.
Quite to the contrary, spatial indexing is crucially important in my application domain and along with polygon clipping, corner stitching tiles and centerline-stick interconnect data model is part of the four cornerstones of physical design VLSI cad software. It is also foundational to a large number of other fields. Well implemented Z-curve/Morton, Hilbert or Sierpinski 2D spatial indexes are what make the difference between an enterprise class data base index and something that merely works. It is the secret sauce in what Oracle sells. It is exactly because it is important that I don't want to rush it.
To my way of thinking the polygon clipping is the killer app that GGL would provide. Most of the other algorithms are things that anyone can implement themselves fairly easily or are specific to GIS. Spatial indexing could be a killer app too, if done well. I had a spatial index in my library but I took it out to submit. It was well suited to CAD, but not ideal for general use as compared to better algorithms. I also took out the segment2d and segment3d data structures and concepts that form the basis for centerline stick interconnect models.
Regards,
Luke
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk