On Tue, Jul 30, 2019 at 4:41 PM Sanders, Marshall (CAI - Atlanta) <
marshall.sande...@coxautoinc.com> wrote:
> I’ll explain the context around the use case we’re trying to solve and
> then attempt to respond as best I can to each of your points. What we have
> is a list of documents that in our case the location is sometimes a point
> and sometimes a circle. These basically represent (in our case) inventory
> at a physical location (point) or inventory that can be delivered to you
> within X km (configurable per document) which represents the circle use
> case. We want to be able to allow a user to say I want all documents
> within X distance of my location, but also all documents that are able to
> be delivered to your point where the delivery distance is defined on the
> inventory (creating the circle).
>
That background info helps me understand things!
> This is why we were actually trying to combine both point based data and
> poly/circle data into a single geospatial field, since I don’t believe you
> could do something like fq=geofilt(latlng, x, y, d) OR
> geofilt(latlngCircle, x, y, 1) but perhaps we’re just not getting quite the
> right syntax, etc.
>
Oh quite possible :-). It would look something like this: fq= {!geofilt
sfield=latLng d=queryDistance} OR {!geofilt sfield=latLngCircle
d=0}&pt=myLocation
Notice the space after the fq= which is critical so that the first
local-params (i.e. first geofilt) does not "own" the entire filter query
string end to end. Due to the space, the whole thing is parsed by the
default lucene/standard query parser, and then we have the two clauses
clearly there. The second geofilt has distance 0; it'd be nice if it
internally optimized to a point but nonetheless it's fine. Alternatively
there's another syntax to embed WKT where you can specify a point
explicitly... something like this: ... {!field f=latLngCircle
v="Intersects(POINT(x y))"}
That said, it's also just fine to do as you were planning -- have one RPT
based field for the shape representation (mixture of points and circles),
and one LLPSF field purely for the center point that is used for sorting.
That LLPSF field would be indexed=false docValues=true since you wouldn't
be filtering on it.
>
> * Generally RptWithGeometrySpatialField should be used over
> SpatialRecursivePrefixTreeFieldType unless you want heatmaps or are willing
> to make trade-offs in higher index size and lossy precision in order to get
> faster search. It's up to you; if you benchmark both I'd love to hear how
> it went.
>
> -We may explore both but typically we’re more interested in speed
> than accuracy, benchmarking it may be a very interesting exercise however.
> For sorting for instance we’re actually using sqedist instead of geodist
> because we’re not overly concerned about sorting accuracy.
>
Okay... though geodist on a LLPSF field is remarkably optimized.
> * I see you are using Geo3D, which is not the default. Geo3D is strict
> about the coordinate order -- counter-clickwise. Your triangle is
> clockwise and thus it has an inverted interpretation -- thus it's a shape
> that covers nearly the whole globe. I recently documented this
> https://issues.apache.org/jira/browse/SOLR-13467 but it's not published
> yet since it's so new.
>
> - Thanks for this clarification as well. I had read this in the
> WKT docs too, again something we tried but really weren’t sure about what
> the right answer was and had been going back and forth on. The
> documentation seems to specify that you need to specify either JTS or
> Geo3d, but doesn’t provide much info/guidance about which to use when and
> since JTS required adding another jar manually and therefore complicates
> our build process significantly (at least vs using Geo3D) we tried Geo3D.
> I’d love to hear more about the tradeoffs and other considerations between
> the two, but sounds like we should switch to JTS (the default, correct?)
>
The default spatialContextFactory is something internal; not JTS or Geo3D.
Based on your requirements, you needn't specify either JTS or Geo3D, mostly
because you don't actually need polygons. I wouldn't bother specifying it
unless you want to experiment with some benchmarking. JTS would give you
nothing here but Geo3D + prefixTree=S2 (in Solr 8.2) might be faster.
> * You can absolutely index a circle in Solr -- this is something cool and
> somewhat unique. And you don't need format=legacy. The documentation needs
> to call t out better, though it at least refers to circles as a "buffered
> point" which is the currently supported way of representing it, and it does
> have one example. Search for "BUFFER" and you'll see a WKT-like syntax to
> do it. BUFFER is not standard WKT; it was added on to do this. The first
> arg is a X Y center, and 2nd arg is a distance in decimal degrees (not
> km). BTW Geo3D is a good choice here but not essential either.
>
> - This sounds very promising and we’ll definitely spend some time
> here because it may ultimately be what we really want to use, sounds like
> Geo3D may actually be the right choice now?\
>
RE Geo3D, shrug... maybe Geo3D with S2 could be a little faster, perhaps.
For lots of circles perhaps, but points, I doubt it.
> One other question I have is what the behavior will be if both my point
> and my search radius are inside of the circle/polygon entirely? Like
> geofilt(x,y,10) and a buffered point (in km instead decimal degrees for
> simplicity) of BUFFER(x y 20km). Will this document return even though my
> filter is entirely inside the polygon, or is it looking for edge
> intersections?
>
It would match; the geofilt and buffered point both represent regions that
intersect.
No prob.
