Re: [JPP-Devel] Feature Collections With Spatial Index and Limited Topology

[Landon B. <sun...@gm...>]

Michael:

Your comments are excellent, as they always are. :] Thanks for taking the
time to respond.

In plug-ins that need a spatial index, I will build anb STR Tree on the fly
for feature collections that aren't already indexed.

Thanks for the suggestion!

In the meantime...perhaps I can run some timing tests on spatial indices.

Landon

On Wed, Sep 17, 2014 at 12:51 PM, Michael Michaud <
m.m...@or...> wrote:

>  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 lis...@li...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
> Jum...@li...
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>