Good point about the C API. I have been happily far removed from the
debate about the C API versus the C++ API. I'll defer to others about
where the line should be drawn - but I can see a good argument for
limiting the width of the C API as much as possible.
Howard Butler wrote:
On May 4,
On May 4, 2010, at 10:54 AM, Martin Davis wrote:
> Sure, why not? At least for in-memory indexes - there are no plans to extend
> this to disk-based indexes.
>
> Reasons are:
> i) The code is there and well-tested
> ii) The index is designed to work well with GEOS objects (although as you
> poi
Howard Butler wrote:
I need GEOS for Touches/Disjoint (topology operations) anyway, so extra
dependencies are not a help, rather the opposite.
Indexing is orthogonal to GEOS main geometry algebra operations, IMO. I don't
like that we expose internal indexing stuff publicly because
On 4 May 2010 14:30, Roger Bivand wrote:
> Hi,
>
> I'm investigating the use of STRtree functions in C API to find candidate
> GEOS_MULTIPOLYGON or GEOS_POLYGON objects to test for contiguity, with
> GEOSDisjoint() or GEOSTouches(). I think that I can see how to build the
> tree with envelopes of
On May 4, 2010, at 9:26 AM, Roger Bivand wrote:
> Thanks for the suggestion.
>
> I'm sorry, but I don't see any documentation whatsoever, after successfully
> building. So "quite easily" is maybe not my impression, I'm afraid, coming
> from C and interfacing with R.
If you've coded with GDAL o
On Tue, 4 May 2010, Howard Butler wrote:
Roger,
I would suggest at least investigating libspatialindex, which is an R*
tree (and linear and quadratic splitting as well) implementation that is
much more featureful than the unexposed internal indexing of GEOS. I
have just added a C API (GDAL
On Apr 11, 2010, at 11:34 AM, strk wrote:
> On Wed, Apr 07, 2010 at 08:14:02AM -0500, Howard Butler wrote:
>> PSC Members,
>>
>> I would like to add Paul Ramsey to the PSC, subject to his acceptance of RFC
>> 2 (which he wrote ;). His history with the project is well known, and now
>> that he
Roger,
I would suggest at least investigating libspatialindex, which is an R* tree
(and linear and quadratic splitting as well) implementation that is much more
featureful than the unexposed internal indexing of GEOS. I have just added a C
API (GDAL or GEOS-style, it's a total rip-off of them)
Hi,
I'm investigating the use of STRtree functions in C API to find candidate
GEOS_MULTIPOLYGON or GEOS_POLYGON objects to test for contiguity, with
GEOSDisjoint() or GEOSTouches(). I think that I can see how to build the
tree with envelopes of the polygon objects, using an int ID number as th
On Wed, 3 Feb 2010, Roger Bivand wrote:
(reverting to list - link to test C code below).
For closure on the thread of touching polygons not being merged by union
operations:
The rgeos R/GEOS interface is now a GSoC project within the R project, and
the "student", Colin Rundel, has found th
10 matches
Mail list logo
