Hi,
I agree with Paul's remark, and add some results I obtained in january
with a 1000000 points dataset :
reading wkt (64Mo) : 48 s
writing wkt (64Mo) : 66 s
reading wkb (64Mo) : 2.5 s
writing wkb (64Mo) : 1.9 s
reading from PostgreSQL sequencially (wkb) : 22 to 95 s (depending on
some options)
reading from PostgreSQL randomly (wkb) : 760 s (extrapolation)
writing to PostgreSQL (hundred points at a time) : 271 s
reading from H2 sequencially (wkb) : 56 s (depending on some options)
reading from H2 randomly (wkb) : 37 s (extrapolation) [comparison with
previous result is strange !]
writing to H2 (hundred points at a time) : 86 s
reading from Access sequencially (wkb) : 80 s (depending on some options)
reading from Access randomly (wkb) : 2800 s (extrapolation)
writing to Access (hundred points at a time) : 663 s
my 2 cents
Michael
Paul Austin a écrit :
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
_______________________________________________
jts-devel mailing list
[email protected]
http://lists.refractions.net/mailman/listinfo/jts-devel
