I agree with Martin!!! Also I can't understand Surveyor really well here... Are you thinking about using shapefiles to persist the FeatureCache???
If yes, it seems a little odd, given all the limits shapfiles have (field names length, data tyeps, etc.). If not, pardon me!!! Anyway, to do the persist, a Java DB would be better suited, like HSQL for example. There's no need for it to be spatial enabled, you can store Geometries as JTS Object inside a "normal" field, then you can read them all from the DB inside a JTS spatial index along with record IDs. But, as Martin suggests, this may be the job of a DataStore. One can simply load it's features from whatever sources they're stored in and then save them to this "smart" data store. Work on them as long as he wants, then save them back to the original format. If one has PostGIS or Oracle available, he doesn't even need it. All this is only needed if the original features are inside shapefiles or some other inefficient file format. If your original data are already inside PostGIS or Oracle, you don't need a FeatureCache at all (but isn't it already built-in inside OJ??? Doesn't it already caches fetures from data stores???). Yes, maybe I'm thinking about browsing now, less about editing...??? But maybe I didn't understand it at all...!!! Sorry for that...!!! Bye Paolo Rizzi > -----Messaggio originale----- > Da: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] conto di > Martin Davis > Inviato: mercoledì 6 giugno 2007 19.00 > A: Sunburned Surveyor > Cc: OpenJUMP Dev > Oggetto: [JPP-Devel] Comments on FeatureCache & the JUMP DataStore API > > > > > 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 > ------------------------------------------------------------------------- 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
