Hi Peter, On Mar 29, 2012, at 11:32 AM, Mattmann, Chris A (388J) wrote:
> Hi Peter, > > On Mar 28, 2012, at 12:45 PM, Peter K wrote: > >> Hi Chris, >> >>> You follow me? Then we could define a chunked load interface as well >> >> yes. What would be wrong with a method like >> boolean put(LatLon latLon, T object) ? > > Nothing at all. I'm fine with templating, that's fine too. > >> >> Also, why does the QuadTreeData requires one to use a filename? > > That's just the current way it's implemented -- it can definitely be improved, > and likely should hold a SpatialData object (which would be similar to the > interface discussed). > > >> And how >> could I e.g. store just one integer at lat/lon or other information? > > B/c Lat/Lons are normally stored in coordinate systems that aren't integer > in nature (e.g., WGS84). At least in the ones I work with. > >> And why is capacity, id and type necessary in QuadTreeNode? > > Because it's really domain specific and needs to be generalized, and > improved to store a SpatialData object, probably. Help welcomed > here. > >> Couldn't >> type be simply replaced by a subclass of a common 'node' interface? > > Agreed. > >> And capacity is (accidentially?) not used - what happens if the data >> node is full? > > Great question -- that's probably a bug? > >> Also getData can be used (and is used) without the capacity limitation - >> or is it just that data.length is the capacity? > > Good question here -- not exactly sure, since I'm not an expert on the > QuadTree. > > Nga -- you around? Can you help? > I agree that the capacity is not needed and data.length is sufficient to represent the capacity of the node. If the node is full, based on the quad tree insertion algorithm, the node should be split and data should be redistributed accordingly. Best, Nga
