[fdo-internals] FDO RFC 63 In-memory Spatial Index - for review

[Greg Boone]

If Gavin has no further concerns, the voting can resume.

+1

Greg

From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Dan Stoica
Sent: Monday, June 25, 2012 3:39 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] FDO RFC 63 In-memory Spatial Index - for review

Hi,

I have addressed Gavin's concerns 10 days ago. Any other concerns so voting can resume?

Thanks,
Dan.


From: Dan Stoica
Sent: Thursday, June 14, 2012 3:37 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] FDO RFC 63 In-memory Spatial Index - for review

Please see inline.

Thanks,
Dan.
From: fdo-internals-bounces at lists.osgeo.org<mailto:fdo-internals-bounces at lists.osgeo.org> [mailto:fdo-internals-bounces at lists.osgeo.org]<mailto:[mailto:fdo-internals-bounces at lists.osgeo.org]> On Behalf Of Gavin Cramer
Sent: Thursday, June 14, 2012 12:54 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] FDO RFC 63 In-memory Spatial Index - for review

I do have more comments, but just have not gotten to reply previously.


1.       Can there be a way to get segment information (at least for line segments) out of the results without having to implement a segment visitor?  At least for callers who need XY information (the main mode of operation for spatial filtering), it only requires two more binary digits (two Boolean values) to encode ordinate order, mapping extents (four doubles in a fixed order) back to the original XY ordinates.  Example, one Boolean indicates whether Min X represents the first X ordinate of the original line segment, and the other Boolean indicates whether the Min Y represents the first Y ordinate of the original line segment.

In order to retrieve the original XY ordinates they have to be stored into the R-tree. The two booleans are not enough. Regardless, a segment visitor is very fast and in my opinion this extra memory consumption is not justified.


2.       The Marker encoding for sub-part and segment index is easy to overflow in Mode 3.  A larger result needs to be available, or at least a return value to indicate an overflow.  Both can be done, so that the caller can just call a different method to get the larger result when needed.

The RFC states the following:

/// In Mode #3 a exception will be thrown in case the encoding fails. In this case Mode #2 can be used instead.


3.       Marker sorting should be supported, especially if #1 above is not supported.  It’s just as useful to callers as the DecodeMarker method.

Not sure marker sorting  fits too well into this RFC. It’s trivial for the client to collect the markers in a standard vector and then call sort().

Gavin


From: fdo-internals-bounces at lists.osgeo.org<mailto:fdo-internals-bounces at lists.osgeo.org> [mailto:fdo-internals-bounces at lists.osgeo.org]<mailto:[mailto:fdo-internals-bounces at lists.osgeo.org]> On Behalf Of Greg Boone
Sent: Thursday, June 14, 2012 12:34 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] FDO RFC 63 In-memory Spatial Index - for review

If there are no comments, I would like to request a vote on this RFC.

+1

Greg

From: fdo-internals-bounces at lists.osgeo.org<mailto:fdo-internals-bounces at lists.osgeo.org> [mailto:fdo-internals-bounces at lists.osgeo.org]<mailto:[mailto:fdo-internals-bounces at lists.osgeo.org]> On Behalf Of Dan Stoica
Sent: Monday, June 04, 2012 11:42 AM
To: FDO Internals Mail List
Subject: [fdo-internals] FDO RFC 63 In-memory Spatial Index - for review

Hi,

Please review the proposal for an in-memory Spatial Index.

http://trac.osgeo.org/fdo/wiki/FDORfc63

Thanks in advance for your feedback,
Dan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/fdo-internals/attachments/20120625/10d82087/attachment-0001.html>