-
Notifications
You must be signed in to change notification settings - Fork 24.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Envelope GeoShape search across dateline doesn't find correct documents. #22564
Comments
@nknize please could you take a look |
Still reproduces in master, but it might make sense to revisit this after #32039 since it changes most of this code. |
That still seems to be an issue after #35320. |
Hi, The problem is that an "envelope" has a different meaning than a "bounding box". The above fix is there to exchange the coordinates if the envelope is not in "cartesian order". If Elasticsearch would support "bounding boxes" (which have a special meaning in the GIS world), then the order of coordinates would be defined (topLeft first, then bottomRight or better northWest, southEast). In that case a box crossing the date line would have a x coordinate (longitude) on the eastern bound of the box that is smaller than the west bound longitude (e.g., west bound is 179, east bound is -179, so its a box crossing date line and spans 2 degrees). In that case its clear that it crosses date border. With envelopes, it's just a box and Elasticsearch just corrects it to be a box in cartesian form, which is broken for spherical coordinates. The work around we are intending at PANGAEA is to use a geometryCollection while indexing and while searching that has 2 separate envelopes (on both sides of date line). This would also solve the user's original request. Of course using polygons is also fine, but that's even more complicated to handle correctly if your own APIs just handle with bboxes. IMHO, Elasticsearch should add another GeoShape type as "bbox" that has the common bounding box semantics used in WGS84. |
👍 I agree.
|
Hi @nknize, |
That's not correct as of the publication of RFC7946:
|
Yes, but the bbox is just metadata for the JSON file. It's not defined as a geometry. But yes, you are right. In general in GeoJSON you should split geometries at date line, but Elasticsearch does not require this for all other datatypes except envelope. |
I just run the following commands in Elasticsearch 8.4.2:
And it returns:
Therefore I am closing this issue as It is fixed. |
Elasticsearch version: 2.2 - 5.1
JVM version:
OS version:
Alpine Linux v3.4 in Docker 1.12.5 Stable on Mac OS 10.12.2
Description of the problem including expected versus actual behavior:
Envelopes create a bounding box that won't cross longitude 180 ( or -180, roughly the international dateline).
Steps to reproduce:
ShapBuilder, in parseEnvelope, modifies the upper left and lower right coordinates. It sets the upper left to the minimum longitude and maximum latitude of the coordinates provided. Lower right gets the maximum longitude and minimum latitude of the coordinates provided. This means that an envelope of [[170, 10], [10, -10]] will not find a polygon with a coordinate or (179,1) as part of a geo_shape query using envelope because the bounds of the envelope will be modified to [[10, 10], [170, -10]]. It's fine to modify the latitude coordinates setting the maximum to the upper left, and the minimum to the upper right, but the longitude coordinates should not be changed.
Here is a simple Sense script that demonstrates the problem. It creates two polygons on the equator, one on the prime meridian and one on the international dateline. It then searches the polygon on the international dateline using an identical polygon and envelope search. The polygon search returns the correct document, the envelope search returns the wrong document.
The text was updated successfully, but these errors were encountered: