lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (JIRA)" <>
Subject [jira] [Commented] (LUCENE-8126) Spatial prefix tree based on S2 geometry
Date Wed, 10 Jan 2018 04:11:00 GMT


David Smiley commented on LUCENE-8126:

This sounds very interesting Ignacio!  In spatial-extras, you can add a dependency on s2.
 Start that way and we can change our minds if it seems we're using a super small piece of

I don't completely understand what you are proposing though.  My understanding of s2 is that
it's sort of a competitor/alternative to Lucene Geo3d.  But come to think of it, I do recall
there was some indexing primitives in there that was apart from the surface-of-sphere shape
implementations.  Ultimately, I assume we're talking about indexing interesting shapes such
as polygons (and surface-of-sphere ones at that); right?  And I figure that this index technique
you have in mind wouldn't replace the need to store the vector/raw implementation to check
for a precise match as we're doing now with Geo3d + RPT, right?  So we're talking about a
faster RPT of sorts using some techniques in s2, using it's code in fact, and of course using
Lucene's terms dictionary (or do you have in mind the Points API) ?

BTW have you seen this benchmark?:  It's
just point data so it's not completely apt here but thought I'd share anyway.

> Spatial prefix tree based on S2 geometry
> ----------------------------------------
>                 Key: LUCENE-8126
>                 URL:
>             Project: Lucene - Core
>          Issue Type: New Feature
>          Components: modules/spatial-extras
>            Reporter: Ignacio Vera
> Hi [~dsmiley],
> I have been working on a prefix tree based on goggle S2 geometry (
to be used mainly with Geo3d shapes with very promising results, in particular for complex
shapes (e.g polygons). Using this pixelization scheme reduces the size of the index, improves
the performance of the queries and reduces the loading time for non-point shapes. 
> If you are ok with this contribution and before providing any code I would like to understand
what is the correct/prefered approach:
> 1) Add new depency to the S2 library (
It has Apache 2.0 license so it should be ok.
> 2) Create a utility class with all methods necessary to navigate the S2 tree and create
shapes from S2 cells (basically port what we need from the library into Lucene).
> What do you think?

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message