David, Thanks for the help. I have downloaded the source code from the CVS for Vivid's JUMP. Is there any Javadoc or other documentation that covers the Datastore framework?
I didn't see any in the directory structure I downloaded from the CVS, or in the Javadoc that is available as part of the JUMP 1.1.1 Source Package. If there isn't any documentation, perhaps you can answer these brief questions: I don't see a "DataStore" interface or implementation in the DataStore package. I do see a DataStoreDirver and a DataStoreConnection. What exactly is a DataStore and how are these classes related? Is a DataStore similar to a RAM-independent FeatureCollection? As I understand it, the legacy JUMP code, and OpenJUMP code reads a spatial data file like a shapefile anc creates an implementation of the FeatureCollection interface. This FeatureCollection is then wrapped in a Layer object and rendered. Does the Vivid JUMP currently in CVS still follow this design? Does a DataStore get wrapped directly by a layer in the way a FeatureCollection does? If not, I think I will still have the same problem... Thanks again for the help. Landon P.S. - If I can't get this figured out I will give you a call, but I wanted to post this to the list for the benefit of the other developers. On 8/22/06, David Zwiers <[EMAIL PROTECTED]> wrote: > Sunburned, > > Most of the required components are readily available. I would look into > leveraging the DataStore framework (Jump CVS) in conjunction with an > indexed SHP reader (GeoTools port / interface?). You need only write the > 'glue code' between the DataStore framework (already does caching based > on the viewing area) and your SHP reader of choice. > > If you need a few more directed hints to get started, feel free to drop > me a line. > > David Zwiers > Vivid Solutions > Telephone : (250) 385-6040 > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Sunburned Surveyor > Sent: August 22, 2006 8:26 AM > To: List for discussion of JPP development and use. > Subject: [JPP-Devel] Refactoring JUMP fpr support of large > spatialdatasets... > > I've been taking a look at the OpenJUMP source code, as well as the > work done by Alvaro on Agiles version of OpenJUMP, in an effort to > come up with a relatively simple solution to the RAM restriction > OpenJUMP has when reading large ESRI Shapefiles or other spatial > datasets. I've hit an obstacle of sorts, and I was hoping some of the > more experienced developers would have a solution. > > Alvaro overcame the RAM restriction by creating an object that > implemented the FeatureCollection interface, but stored its features > on disk, and not in RAM. I had the same idea, and was initially > pleased when I saw Alvaro had pioneered this technique. I didn't > understand why Alvaro had created his own version of the OpenJUMP > core, instead of encapsulating his support for large spatial datasets > in a plug-in. > > Then I read Alvaro's note: > > " In package org.agil.dao, you could see a FeatureCollection > implementation > (FeatureCollectionOnDemand) which read features directly from a > database. > After use it, you must change all JUMP code where get a List from a > FeatureCollection, and change it for an Iterator." > > I took a look at the source code and found that Alvaro was indeed > correct. The FeatureCollection interface has two methods that return a > generic list of all the Feature objects in the FeatureCollection. This > creates a problem, as all of the Feature objects then need to exist in > RAM, which is what we are trying to avoid in the first place. > > One of these two methods, the getFeatures() method, is called 26 times > in other parts of the source code. > > What does this mean? It means both JUMP and OpenJUMP are currently > wired in a way that prevents RAM independent FeatureCollection > implementations without some significant changes to the core source > code. (It would require that all of the methods that expect a list of > all the Features in a FeatureCollection be changed to work with an > Iterator object, as Alvaro suggested.) > > There are a couple of ways to fix this. I want to know which way will > be the simplest and most effective. > > [1] Refactor the OpenJUMP source code to use Iterators instead of > lists when calling the two problem methods of the FeatureCollection > interface. > > [2] Create a "RAM" independent object that implements the Feature > interface instead of a RAM independent implementation of an object the > Feature Collection interface. We could then return a list of these RAM > independent Features. (I'm not sure how this would reduce memory usage > though. Probably not as well as a RAM independent FeatureCollection > implementation. There might also be a pretty severe performance > penalty. ???) > > [3] Create a custom implementation of the Java.Util.List interface > that doesn't require its member objects to be in RAM. The only real > problem I saw with this technique initially is the toArray() method. I > suppose we could return an empty array, because I don't know another > way to implement this method without placing all the Feature Objects > into the array, and thus into RAM. This technique will also ivolve a > bit of work, as the List interface contains quite a few methods. > > I'm really looking for the simplest solution. I have planned a > "spatial database" for OpenJUMP-Ex that will solve this problem in > OpenJUMP's design. So I don't really want to invest a lot of energy > into what I hope will be a temporary "band-ais" solution. > > Thank you for your thoughts. > > The Sunburned Surveyor > > ------------------------------------------------------------------------ > - > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
