Hi Landon,
1 - I prefer STRtree which is faster than quad tree. But you're right,
STRtree is not updatable and may not fit all use cases.
2 - If I correctly understood Jukka's use case, I think it would me much
more easy
to union geometries with same attribute(s), then to explode the
multi-geometry.
Maybe you can save computation time by indexing geometries and computing
topology relation before unioning, but my feeling is that it will be
hard to get
better performance as union has already been optimized by MD.
4 - I have been willing to test MapDB for a long time. If you do so, I'm
interested
to get feedback.
5 - There are many plugins which benefit spatial indexing (ex. plugins
performing
geometric joins, matching, queries...). In these plugins, a STRtree
index is generally
computed during plugin execution. As far as I know, the cpu used by STRtree
calculation is generally quite les than the feature processing, but of
course,
it may depend on what the plugin does exactly. Creating layers using a
QuadTree
index may be useful but you should consider the following points :
- you'll have a small penalty every time you add/remove/paste... a feature
(probably a very small penalty though)
- you must check that the index will be aware of any geometry change
- for plugins using an index, you must make check that making many
queries on
a pre-built quadtree is not slower than building a STRtree as needed and
making
the same queries on this index.
My 2 cents,
Michaël
I've been working a bit on Jukka's idea for a dual attribute merge
plug-in that considers topology. As a first step, I wanted to whip up
a FeatureCollection implementation that features spatial indexing and
storage of some adjacency topology.
Here are a few questions for the group:
1) I noted that we already have an IndexedFeatureCollection class, but
that it is read-only. However, the QuadTree class in JTS appears to
support removal of indexed geometry...so we should be able to have a
read/write indexed feature collection. Any comments on this idea?
2) I'm going to write some code that will calculate and store
(in-memory) polygon adjacency. Does anyone already have code like this
(for JTS geometries) they can share?
4) I'll want to store the spatial index and adjacency topology
on-disk. Has anyone tackled these problems yet? I'm thinking about
using simple text files or maybe using Java MapDB
(http://www.mapdb.org/). What do you think?
5) I figure I'll integrate this indexed feature collection into the
OpenJUMP API with a plug-in. The user can execute the plug-in to
duplicate the currently selected layer to create an indexed feature
collection. Then there will be a set of plug-ins that only work on
these type of feature collections. Any comments on this plan?
Thanks for sharing your thoughts, or any code. I've got part of the
dual merge plug-in GUI written, and I've started on the code for the
indexed feature collection (with topology). All of that code will live
in my SVN. As soon as I have something of substance, I will post a link.
Thanks.
Landon
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
