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) ?
Also, why does the QuadTreeData requires one to use a filename? And how
could I e.g. store just one integer at lat/lon or other information?
And why is capacity, id and type necessary in QuadTreeNode? Couldn't
type be simply replaced by a subclass of a common 'node' interface?
And capacity is (accidentially?) not used - what happens if the data
node is full?
Also getData can be used (and is used) without the capacity limitation -
or is it just that data.length is the capacity?
Regards,
Peter.
> Hi Peter,
>
> On Mar 18, 2012, at 9:11 PM, Peter K wrote:
>
>
>>> Thanks for your email! We don't have any unit tests written yet. We would
>>> love to produce some.
>>> We have a large geolocation dataset here [1]
>> I more meant single unit tests which simply ensures the raw
>> functionality of one a tiny part of the system and are often written
>> when or before the piece of code is written. I think, what you have in
>> mind are more integration tests (not sure though :) !) which tests
>> performance and more complicated bugs when the units play together...
> Yeah that's part of it, but I was also thinking that we could do something
> like the following:
>
> 1. Abstract the storage interface to load the quad tree, e.g.,
> public interface Loadable{
> public QuadTreeNode load(SpatialDataset dataset)
> }
>
> Then have:
>
> public class GeoRSSData extends SpatialDataset{
> //... magic here
> }
>
> public class GeoRSSLoader implements Loadable{
> public QuadTreeNode load(SpatialDataset dataset){
> GeoRSSData data = new GeoRSSData(dataset);
> //...load it into the QuadTree
> }
>
> public class ExcelGeoData extends SpatialDataset{
> //...magic here
> }
>
> public class ExcelLoader implements Loadable{
> //...
> }
>
> You follow me? Then we could define a chunked load interface as well
> (e.g., multiple, chunked call backs to load to reduce mem overhead) and
> then use e.g., the CSV data as a unit test dataset to both test the storage
> interface, and as well, test that the Quad Tree is doing the right thing,
> spatially. Does that make sense? You interested in helping?
>
>> The 'problem' without unit- and only integration-tests would be that you
>> see a test is failing, but you'll need a lot of time to dig into the
>> real reason of the bug. Also executing the unit tests should not take a
>> long time to load values, also IMO unit tests are a great resource for
>> other developers or could even replace documentation ...
> Agreed, we need them :) You're preaching to the choir here.
>
>>> Do you have any ideas in mind that you'd like to help us out on?
>> I'm especially interested in an memory efficient datastructure for a Map ala
>> Map<lat+lon, AnyValue>
>>
>> I've already implemented a very rough prototype of such a Map using a
>> ByteBuffer but now I think a datastructure with 'getNeighbour' would give a
>> huge benefit and I'm looking about possibilities.
> Sounds like a SpatialDataset type :)
>
>>
>>> Help and patches are most welcome!
>> Yeah, I'll definitely have a look into SIS as I'm more digging into graphs
>> and geo stuff now.
> Awesome! Welcome aboard and looking forward to having you part of the
> community!
>
> Cheers,
> Chris
>
>
