Dear Wiki user, You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.
The "SpatialSearch" page has been changed by GrantIngersoll. http://wiki.apache.org/solr/SpatialSearch?action=diff&rev1=16&rev2=17 -------------------------------------------------- The Trie* fields are perfect for representing lat/lon in two distinct fields. Additionally, as of https://issues.apache.org/jira/browse/SOLR-1131, there is now a !PointType that supports transparently representing a point in n-dimensional space in a rectangular coordinate system. Thus, the !PointType might not be appropriate if distance along a sphere or ellipse are desired. ==== Example ==== + {{{<fieldType name="location" class="solr.PointType" dimension="2" subFieldSuffix="_d"/> ... <field name="store" type="location" indexed="true" stored="true"/> }}} - - {{{<fieldType name="location" class="solr.PointType" dimension="2" subFieldSuffix="_d"/> - ... - <field name="store" type="location" indexed="true" stored="true"/> - }}} === LatLonType === - The !LatLonType combines a latitude/longitude point with the characteristics of the !SpatialTileField. All input is interpreted as latitude then longitude. The LatLonType can combine both the features of Spatial Tiles (see below) and filtering by distance. - ==== Example ==== - {{{ <fieldType name="latLon" class="solr.LatLonType" start="4" end="15" subFieldSuffix="_latLon"/> ... <field name="store_lat_lon" type="latLon" indexed="true" stored="true"/> }}} - === Geohash === A geohash is a way of encoding lat/lon into a single field as a String. As of https://issues.apache.org/jira/browse/SOLR-1586, it will be possible to create a geohash via FieldType, simply by passing in a Point (lat,lon). Solr will do the work of converting the point to a geohash. See http://www.geohash.org and http://en.wikipedia.org/wiki/Geohash ==== Example ==== - {{{ <fieldtype name="geohash" class="solr.GeoHashField"/> ... <field name="store_hash" type="geohash" indexed="true" stored="false"/> }}} - === Tiles === (Sometimes called Grids or Tiers or a variety of other things. See http://www.lucidimagination.com/search/document/e0dc70aa8ade729d/spatial_cartesian_tiers_nomenclature#bcf8a28f8d651022 for discussion) @@ -87, +77 @@ See https://issues.apache.org/jira/browse/SOLR-1586 for the !SpatialTileField, which can index points into tiles at multiple levels. ==== Example ==== - {{{ <fieldType name="tile" class="solr.SpatialTileField" start="4" end="15" subFieldSuffix="_tiled"/> ... <field name="store_tiles" type="tile" indexed="true" stored="false"/> }}} - = Indexing = - Indexing is handled by the various !FieldType instances in the schema. At the most basic, the user can represent their own spatial data using ints, floats or doubles. Beyond that, the !PointType, !GeoHashField and !SpatialTileField can be used to index spatial information automatically. = Filtering = @@ -105, +92 @@ 1. By the Spatial Filter QParser (!SpatialQParser) - e.g. {!sfilt fl=location}&pt=49.32,-79.0&d=20 1. Using the "frange" QParser, as in {{{fq={!frange l=0 u=400}hsin(0.57, -1.3, lat_rad, lon_rad, 3963.205)}}} - In practice, for those using Solr's field types above, the Spatial Filter !QParser will automatically make the correct decision about how best to filter. If an application needs a specific type of filtering for performance or other needs, the best bet is to extend the !FieldType in question with your own needs. + In practice, for those using Solr's field types above, the Spatial Filter !QParser will automatically make the correct decision about how best to filter. If an application needs a specific type of filtering for performance or other needs, the best bet is to extend the !FieldType in question with your own needs. == Spatial Filter QParser == - See https://issues.apache.org/jira/browse/SOLR-1568. The following parameters are supported: + + ||<tablestyle="width: 725px; height: 184px;">Parameter||Description||Example|| + + ||<tablestyle="width: 725px; height: 184px;">pt||The Point to use as the center of the filter. Specified as a comma separated list of doubles. If using the !LatLonType, then it is lat,lon.||&pt=33.4,29.0 &pt=27.3,83.9,10.0,5.5 || + ||d||The distance from the point to the outer edge of whatever is being used to filter on (bounding box, pure distance, something else)||&d=10.0|| + ||units||The units of distance. "mi" or "km". Default is miles. All distances are converted to miles internally.||&units=km &units=mi || + ||sphere_radius||The radius of the sphere to be used when calculating distances on a sphere (i.e. haversine). Default is the Earth's mean radius in miles (see org.apache.solr.search.function.distance.Constants.EARTH_MEAN_RADIUS_MI) which is set to 3,958.761458084784856. Most applications will not need to set this. ||&sphere_radius=10.3|| + ||meas||NOTE: This value is experimental and subject to removal. Most applications will not need to change the measure. The !FieldTypes usually make the proper choice given the data stored. The distance measure to use when calculating distance. The default is dependent on the FieldType. Supported values are: 1. hsin - The haversine 2. 0, 1, 2, ... INF for the appropriate p-norm (2 is the Euclidean Distance) ||&meas=hsin.|| + + = Sorting = @@ -126, +122 @@ https://issues.apache.org/jira/browse/SOLR-1578 See https://issues.apache.org/jira/browse/SOLR-1568 = Known Issues = + There are some underlying issues with Lucene's contrib/spatial related to: - There are some underlying issues with Lucene's contrib/spatial related to: * Spatial Tiles and large distances: https://issues.apache.org/jira/browse/LUCENE-1921 * Issues around the poles: https://issues.apache.org/jira/browse/LUCENE-2367 = Useful References = - 1. http://www.movable-type.co.uk/scripts/latlong.html 1. http://www.ibm.com/developerworks/opensource/library/j-spatial/index.html 1. http://www.nsshutdown.com/projects/lucene/whitepaper/locallucene_v2.html
