[ 
https://issues.apache.org/jira/browse/LUCENE-8126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16384663#comment-16384663
 ] 

Ignacio Vera edited comment on LUCENE-8126 at 3/3/18 1:48 PM:
--------------------------------------------------------------

I have come across this problem as well and it was in my next things to do.

S2 prefix tree has the same properties of the other trees : Cells at the same 
level are disjoint and a cell contains all child cells so it could be possible 
to prune bunchy leaves (and it will make the index lighter).

Unfortunately the current implementation only allows this for legacy cells. So 
my proposal is the following:

Create a new interface, that implements the Cell interface, and adds one method:

 
{code:java}
/**
 * Grid cells that share nothing with other cells when calling 
cell.getNextLevelCells() might
 * implement this interface. They will be eligible for prune bunchy leaves.
 */
public interface CellCanPrune extends Cell{

  /**
   * Return the number of children for the current cell.
   *
   * @return the number of children cell.
   */
  int getSubCellsSize();
}{code}
 

That is the only method required for prune bunchy leaves. Implementation for S2 
cells is trivial:

 
{code:java}
@Override
public int getSubCellsSize() {
    if (cellId == null) { //root node
        return 6;
    }
    return  Math.pow(4, tree.arity);
}{code}
 

Make prune code depend on this interface and not legacyCell. What do you think?


was (Author: ivera):
I have come across this problem as well and it was in my next things to do.

S2 prefix tree has the same properties of the other trees : Cells at the same 
level are disjoint and a cell contains all child cells so it could be possible 
to prune bunchy leaves (and it will make the index lighter).

Unfortunately the current implementation only allows this for legacy cells. So 
my proposal is the following:

Create a new interface, that implements the Cell interface, and adds one method:

 
{code:java}
/**
 * Grid cells that share nothing with other cells when calling 
cell.getNextLevelCells() might
 * implement this interface. They will be eligible for prune bunchy leaves.
 */
public interface CellCanPrune extends Cell{

  /**
   * Return the number of children for the current cell.
   *
   * @return the number of children cell.
   */
  int getSubCellsSize();
}{code}
 

That is the only method required for prune bunchy leaves. Implementation for S2 
cells is trivial:

 
{code:java}
@Override
public int getSubCellsSize() {
    if (cellId == null) { //root node
        return 6;
    }
    return  Math.pow(4, arity);
}{code}
 

Make prune code depend on this interface and not legacyCell. What do you think?

> Spatial prefix tree based on S2 geometry
> ----------------------------------------
>
>                 Key: LUCENE-8126
>                 URL: https://issues.apache.org/jira/browse/LUCENE-8126
>             Project: Lucene - Core
>          Issue Type: New Feature
>          Components: modules/spatial-extras
>            Reporter: Ignacio Vera
>            Assignee: Ignacio Vera
>            Priority: Major
>         Attachments: SPT-cell.pdf, SPT-query.jpeg
>
>          Time Spent: 50m
>  Remaining Estimate: 0h
>
> Hi [~dsmiley],
> I have been working on a prefix tree based on goggle S2 geometry 
> (https://s2geometry.io/) 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 
> (https://mvnrepository.com/artifact/io.sgr/s2-geometry-library-java). 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
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to