Bounding cube you mean? Could do. The problem with that is, it turns out that computing the bounding cube is actually the most computationally intensive part of the geography code! So we don't really want to do that for every edge of a shape. My approach is to use "bounding circles" for each edge. I haven't given any thought to whether they would be useful in the large for disk-based indexes (and we have, in any event, a perfectly workable bounding cube implementation), but for the in-memory problem they seem to make sense.
P. On Tue, Jun 1, 2010 at 11:38 AM, Martin Davis <mbda...@refractions.net> wrote: > Perhaps it could use an in-memory bounding prism index? You're using a > disk-based one used for geography types, right? > > Paul Ramsey wrote: >> >> On Mon, May 31, 2010 at 10:27 PM, Paragon Corporation <l...@pcorp.us> wrote: >> >> >>> >>> On that thought. Remember how geometry intersects performance >>> significantly >>> increased with prepared geometry algorithm, are we using that same kind >>> of >>> prepared geometry logic for geography. >>> >> >> No, we are not. The algorithm is currently brute force O(nm). My ideas >> are very similar to the prepared geometry approach, but with some >> changes necessary to work in spherical land (like, what are the index >> leaves? not rectangles...) >> >> P. >> _______________________________________________ >> postgis-users mailing list >> postgis-users@postgis.refractions.net >> http://postgis.refractions.net/mailman/listinfo/postgis-users >> >> > > -- > Martin Davis > Senior Technical Architect > Refractions Research, Inc. > (250) 383-3022 > > _______________________________________________ > postgis-users mailing list > postgis-users@postgis.refractions.net > http://postgis.refractions.net/mailman/listinfo/postgis-users > _______________________________________________ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
