Hi Tom, If you qualify the solution as using BKD (what Lucene now calls "PointValues") then -- no. But that's an implementation detail. In terms of capabilities, if you want to index polygons (as represented on the surface of a sphere, not 2d) in Lucene, then it's possible. See Geo3dRptTest. In particular, Geo3dShape. This test indexes Geo3D shapes (which are surface of a sphere shapes) using the Geo3dShape wrapper so that it appears to be a Spatial4j Shape. With that, it uses a combination of 2 SpatialStrategies, one a grid index (RPT), and the second is the serialized geometry for accuracy. Some "intersect" queries will never need to consult the serialized geometry which then saves a lot of time.
PointValues / BKD is cool. You can represent a multi-dimensional point, or a "hypercube" (many-dimensional box) if you get creative. But it does not yet have an ability to differentiate it's internal cells as having multiple types. The RPT index has a "leaf" cell designator which is used for non-point data (e.g. polygons). This doesn't mean you couldn't use it at all... but it would be difficult (impossible?) to make the index as effective as what RPT can do. For example you could theoretically index a 3D cube of the surface-of-sphere polygon in a PointValues/BKD index. But that's highlight inaccurate to the actual polygon edge. RE S2-Geometry: It's unfortunate that nobody is maintaining it or trying to document it. BTW I'm in FOSS4G Boston the next few days. Perhaps you might be there? ~ David On Mon, Aug 14, 2017 at 2:27 PM Tom Hirschfeld <tomhirschf...@gmail.com> wrote: > Hey, > Is there a way to spatially index polygons that takes advantage of the new > BKD tree functionality? I was looking into the spatial3D api and it appears > that there may be some ability to do this (storing multiple points under > same geo3dpoint field) but it doesn't seem to be well documented if it > exists. Is there a recommended way to support indexing and searching of > polygons (building footprint sized polygons, not huge ones)? If so what is > the currently recommended API to use? We are currently thinking about using > the s2cell library from google. > Best, > Tom Hirschfeld > -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
