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 Fri, 16 Nov 2012 03:50:39 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=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.
+ 

Mime
View raw message