Ignacio Vera commented on LUCENE-8126:

They are in reality spherical polygons with 4 edges not "squares" (aka 
coordinate ranges which close to the poles are more like triangles). You can 
see in the diagram that at 60 degrees horizontal lines are big circles (they 
are slighltly curved on the equirectangular projection).  I am not sure that a 
different projection will help on this case, projection distorts the shapes as 
well as the cells so not sure how much much benefit we will get.

Heatmaps are fantastic to represent data but users needs to be careful as cells 
can represent different areas so results might be bias. In our case we do have 
heatmaps on the sphere but we are using Healpix 
([https://healpix.jpl.nasa.gov/)] to have equal area cells.

I am currently looking into a way to have a benchmark for STP similar to the 
geobenchmark for BKD trees. The difficult part here is all the different 
parameters you can set on a SPT.


I'm having difficulty finding the benchmark; can you provide a link to the GH 


what are you looking for exactly?


Anyway, it would be nice to have this SPT commited, so my question is which 
branches should I commit it? Not sure what is the policy here.






> 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: 0.5h
>  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

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

Reply via email to