[ https://issues.apache.org/jira/browse/LUCENE-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14510688#comment-14510688 ]
Michael McCandless commented on LUCENE-6450: -------------------------------------------- This patch looks wonderful [~nknize]! Hmm in this code: {noformat} + @Override + protected final AcceptStatus accept(BytesRef term) { + AcceptStatus status = super.accept(term); + if (status != AcceptStatus.YES) { + return status; + } {noformat} ... do you also need to more carefully handle the AcceptStatus.YES_AND_SEEK case? Oh I see: NumericRangeTermsEnum never returns this ... maybe add an "assert status != AcceptStatus.YES_AND_SEEK"? Can we just expose simple ctors for these queries instead of the static factory methods? For GeoPolygonQuery, why do we have public factory method that takes the bbox? Shouldn't this be private (bbox is computed from the polygon's points)? Or is this for expert usage or something? In GeoPolygonTermsEnum, the comment "// final-filter by bounding box" should really be "// second-pass filter by bounding box" right? The "final" filter is the polygon check... That GeoUtils.pointInPolygon method is magic to me :) I had no idea it was so simple to check if a point is inside a polygon. Is there a requirement that these poly points are clockwise or counter-clockwise order or something? > Add simple encoded GeoPointField type to core > --------------------------------------------- > > Key: LUCENE-6450 > URL: https://issues.apache.org/jira/browse/LUCENE-6450 > Project: Lucene - Core > Issue Type: New Feature > Affects Versions: 5.x > Reporter: Nicholas Knize > Priority: Minor > Attachments: LUCENE-6450.patch > > > At the moment all spatial capabilities, including basic point based indexing > and querying, require the lucene-spatial module. The spatial module, designed > to handle all things geo, requires dependency overhead (s4j, jts) to provide > spatial rigor for even the most simplistic spatial search use-cases (e.g., > lat/lon bounding box, point in poly, distance search). This feature trims the > overhead by adding a new GeoPointField type to core along with > GeoBoundingBoxQuery, GeoPolygonQuery, and GeoDistanceQuery classes to the > .search package. This field is intended as a straightforward lightweight type > for the most basic geo point use-cases without the overhead. > The field uses simple bit twiddling operations (currently morton hashing) to > encode lat/lon into a single long term. The queries leverage simple > multi-phase filtering that starts by leveraging NumericRangeQuery to reduce > candidate terms deferring the more expensive mathematics to the smaller > candidate sets. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org