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. -
