Sunburned Surveyor wrote: > > I guess I envision the FeatureCache as more of an internal data > manager than I do a data source. The idea is that you suck in features > from any of OpenJUMP's existing DataStores and store them in the > FeatureCache. You'll only need to do this for Layers that will contain > lots of features and might possible max out of your RAM. > > If you have suggestions on how I can implement this particular aspect > of the FeatureCache I'd like to hear them. At this point I plan on > using GeoTools or Deegree ESRI Shapefile code so that I can access one > feature at a time from a Shapefile. (I can't do this with the current > Shapefile driver.) I can do this in an new Shapefile driver that is > written and used just in my FeatureCache, or I can rewrite the > exsiting Shapefile DataStore to provide this access. > > In the long run, I'd really like to see a DataStore interface that > allowed single-feature-access. For example, at some point I may want > to read in huge DXF files as well. It sounds to me like you are trying to build the same functionality that currently exists in spatially-enable DBs - that is, fast access to ranges of features. That's fine - it's appealing to have a lightweight, free FeatureCache implementation, which is perfectly matched to the job of storing JUMP Features (unlike most SDB's, which all have their own idiosyncracies of storage model). If it was me I might investigate the possibility of using an existing Java DB, with possibly some spatial enhancements. (You yourself suggested this in a different context...). You're going to develop most of the same functionality anyway, and you'll never get the maturity of the existing DBs.
My point about the DataStore is that you need to expose your great new Cache to JUMP in some way. The DataStore API is designed to do just this - it let's the JUMP renderer query a range of features from a datastore in a streaming fashion. I think you should target your FeatureCache to be simply another kind of DataStore. That way, you get all the existing functionality of DataStores - streaming, interruptible drawing, querying by range, connection lifecycle, UI, etc. Otherwise, you're going to have to build all this yourself, in yet another new framework. If you need more functionality exposed, this should become enhancements to the DS framework, since likely other use cases will need this as well. Now, one baby step in this direction is to expose the GT indexed Shapefile as a DataStore. This should be easy to do, and right away we will have the ability to view large shapefiles. If you are wanting DXF as well, then you have a choice to make. DXF doesn't have any indexing AFAIK, so you'll either have to build this, or move the data into some other format which does. This is a good discussion - I'll be interested to hear other's comments. My main goal is to have a single API/framework for accessing large datastores. That way, all additional work benefits everyone. HTH - M > > I'm not sure what the best way is to achieve this. If you have > suggestions, please let me know. > > Thanks again for all of your help. > > Landon > > > On 6/6/07, Martin Davis <[EMAIL PROTECTED]> wrote: >> First of all, I don't think you (or JUMP) has to commit to a single >> library for different pieces of functionality. I think the Feature >> model question is separate from the issue of which Shapefile I/O >> implementation to use. So if you like the deegree one, just use that. >> I don't really know which library is likely to be better quality or more >> stable. I guess for Shapefiles I'd probably vote for using GT, but not >> really for any hard reason. But I agree about your comment about >> deegree being more supportive of OJ - we probably want to encourage >> that! >> >> Another point in favour of deegree is that the GT change process seems >> very cumbersome and slow. I've always prefereed a smaller group to work >> with, so change can be made faster. >> >> The important thing is to isolate these various components behind >> well-defined interfaces in JUMP, so that they can be swapped out if >> need be. >> >> By the way, are you looking at using the DataStore framework as the API >> to your "Shapefile cache"? It doesn't make sense to use the existing >> DataSource Reader, since it only reads an entire collection at a time. >> Or are you making yet another API? In that case, I'd be concerned, since >> OJ would then have three different data access APIs. >> >> M >> >> Sunburned Surveyor wrote: >> > Martin, >> > >> > After poking around a little in the Javadoc for the Deegree project I >> > see that it has everything I need for single feature access to an ESRI >> > Shapefile. The library also seems a little more stable than GeoTools, >> > and I think the folks at Deegree are more supportive of the work in >> > OpenJUMP than the folks at GeoTools. (I don't even think any of the >> > GeoTools folks are subscribed to the JPP mailing list, except for you >> > of course.) :] >> > >> > Do you have any thoughts on which library would be the best to use? I >> > was pretty set on getting more familiar with GeoTools, but Markus made >> > some good arguments in his e-mail. >> > >> > What would be the best for OpenJUMP in the long run? What would be the >> > best for the open source Java GIS community in the long run? >> > >> > I know you are busy, and I appreciate the time you take to read and >> > respond to my e-mail. >> > >> > Landon >> > >> > P.S. - I might also bounce this off of David at Vivid Solutions to see >> > if he has any comments. >> >> -- >> Martin Davis >> Senior Technical Architect >> Refractions Research, Inc. >> (250) 383-3022 >> >> -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
