[ https://issues.apache.org/jira/browse/SOLR-10039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Smiley resolved SOLR-10039. --------------------------------- Resolution: Fixed Fix Version/s: 6.5 > LatLonPointSpatialField > ----------------------- > > Key: SOLR-10039 > URL: https://issues.apache.org/jira/browse/SOLR-10039 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: spatial > Reporter: David Smiley > Assignee: David Smiley > Fix For: 6.5 > > Attachments: SOLR_10039_LatLonPointSpatialField.patch, > SOLR_10039_LatLonPointSpatialField.patch, > SOLR_10039_LatLonPointSpatialField.patch, > SOLR_10039_LatLonPointSpatialField.patch > > > The fastest and most efficient spatial field for point data in Lucene/Solr is > {{LatLonPoint}} in Lucene's sandbox module. I'll include > {{LatLonDocValuesField}} with this even though it's a separate class. > LatLonPoint is based on the Points API, using a BKD index. It's multi-valued > capable. LatLonDocValuesField is based on sorted numeric DocValues, and thus > is also multi-valued capable (a big deal as the existing Solr ones either > aren't or do poorly at it). Note that this feature is limited to a > latitude/longitude spherical world model. And furthermore the precision is > at about a centimeter -- less precise than the other spatial fields but > nonetheless plenty good for most applications. Last but not least, this > capability natively supports polygons, albeit those that don't wrap the > dateline or a pole. > I propose a {{LatLonPointSpatialField}} which uses this. Patch & details > forthcoming... > This development was funded by the Harvard Center for Geographic Analysis as > part of the HHypermap project -- This message was sent by Atlassian JIRA (v6.3.15#6346) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org