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 "SolrAdaptersForLuceneSpatial4" by DavidSmiley
Date Mon, 15 Oct 2012 05:40:48 GMT
Dear Wiki user,

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

The "SolrAdaptersForLuceneSpatial4" page has been changed by DavidSmiley:
http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4?action=diff&rev1=8&rev2=9

Comment:
Polygon - Rectangle gotcha, and other tweaks

  
  Shapes other than point, circle, or rectangle require JTS, an otherwise optional dependency.
 If you want to use WKT but only need the basic shapes, you still need JTS -- a restriction
likely to be addressed in the near future.
  
-  * JTS views the world as a flat plane; the latitude and longitude are mapped to this plane
directly.  It uses Euclidean math operations, not Geodesic ones.  By and large this isn't
a problem, although it can be if the vertices are particularly far apart longitudinally. 
Spatial4j adapts shapes that cross the dateline to be compatible with JTS, and so you shouldn't
notice a problem (notwithstanding unknown bugs).  It does not support shapes covering the
poles yet.  Consequently if you want to index or query by the Antarctica polygon for example,
you are out of luck for now.
+  * Due to a combination of things, JTS can't simply be referenced by a "<lib>" entry
in solrconfig.xml; it needs to be in WEB-INF/lib in Solr's war file, basically.
+  * JTS views the world as a flat plane; the latitude and longitude are mapped to this plane
directly.  It uses Euclidean math operations, not Geodesic ones.  This effectively warps shapes
slightly, although it can be a bit much if the vertices are particularly far apart longitudinally.
+  * Spatial4j adapts shapes that cross the dateline to be compatible with JTS, and so you
shouldn't notice a problem (notwithstanding unknown bugs).  It does not support shapes covering
the poles yet.  Consequently if you want to index or query by the Antarctica polygon for example,
you are out of luck for now.  The only shape that can encompass a pole is a Circle.  Technically
a longitude-wrapping (-180 to +180) lat-lon box that touches a pole will too though.
-  * Only Polygon, and MultiPolygon WKT types have been tested.  GeometryCollection will not
work but the others should in theory.  Holes in polygons haven't been tested but there is
code to support them.
+  * Only Polygon, and MultiPolygon WKT types have been tested.  GeometryCollection will not
work but the others like LineString should in theory.  Holes in polygons haven't been tested
but there is code in place to support them.
-  * The implementation doesn't support WKT that encompasses a pole.  The only shape that
can encompass a pole is a Circle.  Technically a longitude-wrapping (-180 to +180) lat-lon
box that touches a pole will too though.
   * Polygons and other WKT must have each vertex less than 180 degrees in longitude difference
than the vertex before it, or else it will be confused as going the wrong way around the globe.
 Dateline crossing '''is''' supported.
-  * All WKT coordinates are normalized into the standard geospatial lat-lon boundaries. 
So, -184 longitude becomes +176, for example.  Both +180 and -180 are kept distinct (true
for all of Spatial4j, not just JTS.
+  * All WKT coordinates are normalized into the standard geospatial lat-lon boundaries. 
So, -184 longitude becomes +176, for example.  Both +180 and -180 are kept distinct -- true
for all of Spatial4j, not just JTS.
+  * The standard way to specify a rectangle in WKT is a Polygon -- WKT doesn't have a rectangle
shape.  If you want to specify a Rectangle via WKT (instead of the Spatial4j basic non-WKT
syntax), you should take care to specify the coordinates in counter-clockwise order, the WKT
standard.  If this is done wrong then the rectangle will go the opposite direction longitudinally,
even if it means one that spans nearly the entire globe (>180 degrees width).  OpenLayers
seems to not honor the WKT standard here, and depending on the corner you drag the rectangle
from, might use a clockwise order.  Some systems like PostGIS don't care what the ordering
is, but the problem there is that there is then no way to specify a rectangle that has >=
180 width because there would be ambiguity.  Spatial4j follows the WKT spec.
  
  == Search ==
  
- Searching with the new spatial module is used significantly different than Solr 3 spatial.
 Here is a Solr filter query parameter for a lat-lon bounding box:
+ Searching with the new spatial module is used significantly different than Solr 3 spatial.
 Here is a Solr filter query parameter for a lat-lon bounding box using the simple shape syntax
(non-WKT):
  
  {{{	fq=geo:"Intersects(-74.093 41.042 -69.347 44.558)"  }}}
  
@@ -111, +113 @@

  
  {{{	fq=geo:"Intersects(POLYGON((-10 30, -40 40, -10 -20, 40 20, 0 0, -10 30))) distErrPct=0"
}}}
  
+ == Sorting and Relevancy ==
  
- == Final Notes ==
+ TODO
  
- This documentation is in-progress.  Distance sorting and relevancy boosting are not yet
documented.
- 

Mime
View raw message