lucene-solr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Solr Wiki] Update of "SpatialSearchDev" by YonikSeeley
Date Thu, 10 Mar 2011 17:29:23 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.

The "SpatialSearchDev" page has been changed by YonikSeeley.
The comment on this change is: moving out docs that are not up to snuff, confusing (which
fieldType do I use and why?) or refer to features that are not ready for general use (i.e.
geohash).
http://wiki.apache.org/solr/SpatialSearchDev?action=diff&rev1=3&rev2=5

--------------------------------------------------

- Spatial Search (docs + features under development).  '''Examine SpatialSearch prior to this
page if you have not already.'''
+ = Spatial Search (docs + features under development). =
+ Examine SpatialSearch prior to this page if you have not already.
  
- ==== Example ====
+ ''''''Solr also supports other spatial capabilities beyond just latitude and longitude.
 For example, a PointType can be used to represent a point in an n-dimensional space.  This
can be useful, for instance, for searching in CAD drawings or blueprints.  Solr also supports
other distance measures.  See the FunctionQuery page for more information and look for hsin,
ghhsin and others.
+ 
+ == Field Types ==
+ === PointType ===
  {{{
  <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.  All input is interpreted as latitude
then longitude.  The LatLonType is similar to !PointType, but it does distance calculations
based on Great Circle (haversine) and is only two dimensional (lat/lon).
@@ -31, +33 @@

  <field name="store_hash" type="geohash" 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 !LatLonType can be used to index spatial information automatically.
+ 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 !LatLonType can be used to index spatial information automatically.
  
  When indexing, the format is something like:
  
@@ -47, +49 @@

   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.
@@ -59, +61 @@

  The following parameters are supported:
  ||<tablewidth="725px" tableheight="184px">Parameter ||Description ||Example ||
  ||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).  Must be greater than or equal to 0 ||&d=10.0
||
+ ||d ||The distance from the point to the outer edge  of whatever is being used to filter
on (bounding box, pure distance,  something else).  Must be greater than or equal to 0 ||&d=10.0
||
- ||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 kilometers (see org.apache.lucene.spatial.DistanceUtils.EARTH_MEAN_RADIUS_KM)
which is set to 6371.009.  Most applications will not need to set this. ||&sphere_radius=10.3
||
+ ||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 kilometers (see org.apache.lucene.spatial.DistanceUtils.EARTH_MEAN_RADIUS_KM)
which is set to 6371.009.  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. ||
+ ||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. ||
  
  
  
  
- For !LatLonType, the sfilt command calculates a bounding box by calculating the East and
West Longitudes and the North and South Latitudes of a box that transcribes the circle with
radius d (using hsin).  There are other ways that this can be implemented by overriding the
createSpatialQuery method on !LatLonType.
+ For !LatLonType,  the sfilt command calculates a bounding box by calculating the East and
 West Longitudes and the North and South Latitudes of a box that  transcribes the circle with
radius d (using hsin).  There are other ways  that this can be implemented by overriding the
createSpatialQuery  method on !LatLonType.
  
  For !PointType, the bounding box is calculated by standard rectangular coordinate system
measures.
  
  == Filtering Caveats ==
  === North/South Poles ===
- When the bounding box includes a Pole, then the !LatLonType will automatically switch from
producing a bounding box to a "bounding bowl" (i.e. a spherical cap: http://mathworld.wolfram.com/SphericalCap.html)
whereby it will include all values that are North or South of the latitude of the would be
bounding box (the lower left and the upper right) that is closer to the equator.  In other
words, we still calculate what the coordinates of the upper right corner and the lower left
corner of the box would be just as in all other filtering cases, but we then take the corner
that is closest to the equator (since it goes over the pole it may not be the lower left,
despite the name) and do a latitude only filter.  Obviously, this means there will be more
matches than a pure bounding box match, but the query is much easier to construct and will
likely be faster, too.
+ When the bounding box includes a Pole, then the !LatLonType will automatically switch from
producing a bounding box to a "bounding bowl" (i.e. a spherical cap: http://mathworld.wolfram.com/SphericalCap.html)
 whereby it will include all values that are North or South of the  latitude of the would
be bounding box (the lower left and the upper  right) that is closer to the equator.  In other
words, we still  calculate what the coordinates of the upper right corner and the lower  left
corner of the box would be just as in all other filtering cases,  but we then take the corner
that is closest to the equator (since it  goes over the pole it may not be the lower left,
despite the name) and  do a latitude only filter.  Obviously, this means there will be more
 matches than a pure bounding box match, but the query is much easier to  construct and will
likely be faster, too.
  
  = Sorting =
- https://issues.apache.org/jira/browse/SOLR-1297 added the ability to sort by function, so
sorting by distance is now simply a matter of sorting using the appropriate distance function,
just like boosting.
+ https://issues.apache.org/jira/browse/SOLR-1297  added the ability to sort by function,
so sorting by distance is now  simply a matter of sorting using the appropriate distance function,
just  like boosting.
  
  = Scoring =
  Scoring by distance works just like any other FunctionQuery.  See the distance methods on
the FunctionQuery page for examples and method signatures.

Mime
View raw message