On 11/1/07, stephen white <[EMAIL PROTECTED]> wrote: > > On 31/10/2007, at 6:57 AM, J. Andrew Rogers wrote: > > If you restrict yourself to tracking points, you can make > > assumptions that allow significant data structure optimization. > > Polygons are much more difficult to generalize in a scalable way > > because there is no guarantee that a natural boundary exists with > > which to nicely partition any arbitrary set of polygons. Handling > > this case well is difficult. > > I had this problem, and concluded that the only way of tracking > arbitrary shapes was to define that shape with an embedded scripting > language. The language can then describe areas of interest in > arbitrary ways. > > As far as I know (which is probably not too far) most tracking apps seem like they can get by doing 2D rectangular queries on a set of moving objects which can be represented by their bounding boxes and put in some kind of 2D index grid. Under what kinds of circumstances is this unacceptable?
Also I'm not sure I see that maining read/write consistency on a spatial data index is so vital, for a tracking app. Let's say that you had some moving objects, and wanted to find the one that is closest to some landmark. As long as you can get a mostly-optimized list of probably good estimates for the right answer (from a possibly slightly outdated index), the time you save in culling out the rest of the data set outweighs the time taken to exactly check all the potential answers. Thus data locking constraints can be relaxed to the point where they may not be a bottleneck.
_______________________________________________ Geowanking mailing list [email protected] http://lists.burri.to/mailman/listinfo/geowanking
