Landon, If all you are going to do is store the geometries in the DB, would WKB be a better choice than WKT as the storage requirements should be less, parsing (maybe? quicker) and there will definitely be less IO due to the reduced amount of data going back and forth with the DB.
Paul Sunburned Surveyor wrote: > Micheal, > > I have been working on a FeatureCache for OpenJUMP that would do > exactly what you are talking about. I was going to use binary files to > overcome the speed problem you mentioned. > > However, in the last week or two I've been thinking about implementing > the FeatureCache using HSQL. I was going to store the JTS geometry in > WKT in the tables. I know this will probably be slower than using > binary files, but I hope to add support for "non-spatial" features to > OpenJUMP at some point in the future, and I thought it would be > helpful to already have experience using HSQL for persistent storage > in OpenJUMP. > > The advantage of using HSQL for non-spatial feature storage is that we > get to pick up all the "database" features for "free". I was against > this before, since I didn't want to mess with JDBC and tricky database > set-up, but the small size of HSQL and its ease of use as an embedded > database may be winning me over. > > Another advantage of using HSQL for the FeatureCahce is that it will > be quicker that writing readers and writers for binary files. > > The Sunburned Surveyor > > On 9/28/07, Michaël Michaud <[EMAIL PROTECTED]> wrote: > >> Hi Sunburned Surveyor, >> >> It is easy to build an Indexed FeatureCollection in OpenJUMP. >> Serialization is another problem. >> A way I already explored a little is to create a FeatureOnDemand an a >> FeatureCollectionOnDemand >> A FeatureOnDemand will read data on-disk each time you call getGeometry >> or getAttribute() >> You can keep FeatureCollectionOnDemand or better, >> IndexedFeatureCollectionOnDemand in memory as you only have a few >> dizains of bytes per feature in this FeatureCollection (mainly an id, an >> envelope and an adress to read in the file). >> Tests I did were quite good from the memory point of view, but the >> drawback concerning performance was unacceptable (in my use case, I let >> the on-disk data in its original text format, which may be a bad idea as >> scanning was quite slow). I think the scalable shapefile driver from >> agile use something similar (may be with a possibility to persist the >> index too). >> An interesting test I'd like to do is the same experiment but with a >> database : an in-memory indexed feature collection and features selected >> on-demand from a database with geometry in wkb. >> >> Michael >> >> >> Sunburned Surveyor a écrit : >> >> >>> Thanks for that possible solution David. I was hoping there might be a >>> built-in serialization routine. >>> >>> I asked because I still think it would be great to create a >>> FeatureCollection with a spatial index that can replace the current >>> FeatureCollection we are using in OpenJUMP. This could potentially >>> speed up a lot of different processes in OpenJUMP, like rendering and >>> object snapping for cursor tools. >>> >>> I'll have to take a look at the Quadtree class to see what I might do >>> about supporting persistent storage. >>> >>> Thanks, >>> >>> The Sunburned Surveyor >>> >>> On 9/25/07, David Zwiers <[EMAIL PROTECTED]> wrote: >>> >>> >>> >>>> SS, >>>> >>>> You could complie your own copy of the QuadTree package after having each >>>> class within the package implement Serializable. This would allow you to >>>> use native java storage. >>>> >>>> >>>> David Zwiers >>>> Vivid Solutions Inc. >>>> >>>> -----Original Message----- >>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gabriel >>>> Roldán >>>> Sent: September 25, 2007 11:26 AM >>>> To: [email protected] >>>> Subject: Re: [jts-devel] Curve Approximation and Spatial Index >>>> Serialization >>>> >>>> On Tuesday 25 September 2007 19:00:56 Sunburned Surveyor wrote: >>>> >>>> >>>> >>>>> Does anyone have source code that creates linear approximations (as >>>>> JTS Geometrys) of curved geometries like circular or elliptical arcs? >>>>> >>>>> >>>>> >>>> Hi, >>>> here it is for the arc of circumference case: >>>> http://svn.geotools.org/udig/community/axios/udig-extensions/trunk/plugins/es.axios.udig.ui.editingtools/src/es/axios/udig/ui/editingtools/arc/internal/ArcBuilder.java >>>> >>>> The procedure is easy to extend to other curve types from a Java2D >>>> PathIterator. >>>> >>>> >>>> >>>> >>>>> Also, has anyone come up with a good way to store a Quadtree from JTS >>>>> on disk, and to restore a Quadtree from JTS to memory? >>>>> >>>>> >>>>> >>>> not sure about this one, sorry. >>>> >>>> Gabriel >>>> >>>> >>>> >>>>> Thanks, >>>>> >>>>> The Sunburned Surveyor >>>>> _______________________________________________ >>>>> jts-devel mailing list >>>>> [email protected] >>>>> http://lists.refractions.net/mailman/listinfo/jts-devel >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> jts-devel mailing list >>>> [email protected] >>>> http://lists.refractions.net/mailman/listinfo/jts-devel >>>> >>>> >>>> _______________________________________________ >>>> jts-devel mailing list >>>> [email protected] >>>> http://lists.refractions.net/mailman/listinfo/jts-devel >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> jts-devel mailing list >>> [email protected] >>> http://lists.refractions.net/mailman/listinfo/jts-devel >>> >>> >>> >>> >>> >> _______________________________________________ >> jts-devel mailing list >> [email protected] >> http://lists.refractions.net/mailman/listinfo/jts-devel >> >> > _______________________________________________ > jts-devel mailing list > [email protected] > http://lists.refractions.net/mailman/listinfo/jts-devel > _______________________________________________ jts-devel mailing list [email protected] http://lists.refractions.net/mailman/listinfo/jts-devel
