>> I see that it still depends on JTS. > > Correction: LatLonPoint most definitely does NOT depend on JTS
I’m sorry this is my mistake, I was using org.locationtech.spatial4j.context.jts.JtsSpatialContext in my example which depends on JTS. However I now realize I’m able to switch to org.locationtech.spatial4j.context.SpatialContext and my example works fine because I’m only indexing points and searching for points within a polygon and LatLonPoint handles this (in conjunction with LatLonPointInPolygonQuery). Thank you for pointing that out. Randy > On Jun 8, 2016, at 10:28 AM, Michael McCandless <luc...@mikemccandless.com> > wrote: > > On Tue, Jun 7, 2016 at 3:43 PM, Randall Tidd <r...@tidd.cc> wrote: > > With LatLonPoint.newPolygonQuery() it looks like I don’t need Spatial4j at >> all any more either. This makes my case very simple, I only have to index >> LatLonPoint’s and then do a query search with >> LatLonPoint.newPolygonQuery(). I see that it still depends on JTS. >> > > Correction: LatLonPoint most definitely does NOT depend on JTS. It has no > external dependencies, was designed to have a very simple API, and builds > on Lucene 6.0's new dimensional points to enable fast "point in > polygon/distance/box" filters at search time. > > There's also LatLonDocValuesField if you want to sort hits by distance. > > If you need to do more advanced spatial stuff, like indexing shapes, then > you should look at the spatial-extras module with the JTS dependency. > > Mike McCandless > > http://blog.mikemccandless.com --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
