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=20&rev2=21 Comment: Refactor: Move JTS to bottom and make heading 1 In WKT, coordinates are in "x y" (lon lat) order, and the coordinates are each separated by commas. ''(The double parenthesis is not a typo; see the WKT spec.)'' - == JTS / WKT / Polygon notes == - - Shapes other than point, circle, or rectangle require [[http://sourceforge.net/projects/jts-topo-suite/|JTS]], an otherwise optional dependency. If you want to use [[http://en.wikipedia.org/wiki/Well-known_text|Well Known Text]] (WKT) but only need the basic shapes, you still need JTS -- a restriction likely to be addressed in the near future. - - * 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. - * Dateline crossing '''is''' supported. Spatial4j adapts shapes that cross the dateline to be compatible with JTS, and so you shouldn't notice a problem (notwithstanding unknown bugs). - * Pole wrapping '''is not''' supported. Consequently if you want to index or query by an 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. - * 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. - * WKT shapes 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. The only exception to this is a Polygon representing a rectangle. - * 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 done 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): @@ -157, +144 @@ Just divide instead of multiply to go the other way. + = JTS / WKT / Polygon notes = + + Shapes other than point, circle, or rectangle require [[http://sourceforge.net/projects/jts-topo-suite/|JTS]], an otherwise optional dependency. If you want to use [[http://en.wikipedia.org/wiki/Well-known_text|Well Known Text]] (WKT) but only need the basic shapes, you still need JTS -- a restriction likely to be addressed in the near future. + + * 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. + * Dateline crossing '''is''' supported. Spatial4j adapts shapes that cross the dateline to be compatible with JTS, and so you shouldn't notice a problem (notwithstanding unknown bugs). + * Pole wrapping '''is not''' supported. Consequently if you want to index or query by an 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. + * 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. + * WKT shapes 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. The only exception to this is a Polygon representing a rectangle. + * 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. +
