LUCENE-8903: Add LatLonShape point query

[iverase]

Adds a query to LatLonShape that filters by a provided point.

[jpountz]

How much does it help? :)

[jpountz]

do we really need a relation or can we just assume INTERSECTS?

[iverase]

Not sure, I would keep it like that for two reasons:

• Keep it consistent with all the other queries in LatLonShape

• You can build queries like give me all my shapes that do not contain this point. For Within it becomes a term query matching all indexed point which encoded value are equal to the encoded value of the query.

[jpountz]

s/bounding box/point/

[jpountz]

leftovers?

[iverase]

It seems all this verify functions contain this piece of logic. I guess they were introduced for debugging so I don't want to change it in this PR.

[iverase]

In the dataset I am working with I get speed ups of around 10%:

||op||Approach||Shape||M hits/sec      ||QPS            ||Hit count      ||
                 ||Dev||Base ||Diff||Dev||Base||Diff||Dev||Base||Diff||
|intersects|bkd|point|39.89|35.52|12%|49.71|44.26|12%|180557100|180557100| 0%|

[iverase]

Going a bit more in detail, I wrote the following test to prove a difference between LatLonPoint and LatLonShape:

 public void testPointShapeEquivalence() throws Exception {
    Directory dir = newDirectory();
    RandomIndexWriter writer = new RandomIndexWriter(random(), dir);
    Document document = new Document();
    BaseLatLonShapeTestCase.Point p = (BaseLatLonShapeTestCase.Point) BaseLatLonShapeTestCase.ShapeType.POINT.nextShape();
    Polygon polygon = GeoTestUtil.nextPolygon();

    Field[] fields = LatLonShape.createIndexableFields("LatLonShape", polygon);
    for (Field f : fields) {
      document.add(f);
    }
    LatLonPoint latLonPoint = new LatLonPoint("LatLonPoint", p.lat, p.lon);
    document.add(latLonPoint);
    writer.addDocument(document);

    //// search
    IndexReader r = writer.getReader();
    writer.close();
    IndexSearcher s = newSearcher(r);

    // search both and check same result
    Query q1 = LatLonShape.newPointQuery("LatLonShape", QueryRelation.INTERSECTS, p.lat, p.lon);
    Query q2 = LatLonPoint.newPolygonQuery("LatLonPoint", polygon);
    assertEquals(s.count(q1), s.count(q2));
    IOUtils.close(r, dir);
  }

The test basically index a shape and make a point query and at the same time it index the same point a make a polygon query with the same polygon. It will eventually fail because in LatLonShape, both polygon and point work on the encoding space. On the other hand for LatLonPoint, the query polygon does not work on the encoding space.

[nknize]

I think this is duplicate of LUCENE-8670 which I opened and posted a patch back at the end of January. If I remember right, the only reason we were holding off on that patch was because querying by MULTIPOINT (array of points) were done brute force and we had discussed ways of speeding it up using a simple in memory R tree. It looks like this is a slimmed down version that only accepts a single point. Perhaps we iterate on LUCENE-8670 and improve this query for multiple points?

[iverase]

I think that can be solved by #770 (LUCENE-8746). This is actually what is proposed, to create an R-tree structure when creating a multi-shape.

[nknize]

LGTM

[nknize]

duplicate of?

lucene-solr/lucene/sandbox/src/java/org/apache/lucene/geo/Tessellator.java

Line 795 in ac209b6

public static boolean pointInTriangle (double x, double y, double ax, double ay, double bx, double by, double cx, double cy) {