Spatial queries with bounding box give incorrect results

15981
Reporter: rdmpage
Assignee: fmendez
Type: Bug
Summary: Spatial queries with bounding box give incorrect results
Priority: Blocker
Resolution: Fixed
Status: Resolved
Created: 2014-06-22 22:00:43.772
Updated: 2014-06-27 14:27:29.893
Resolved: 2014-06-27 14:27:29.861
        
Description: Spatial queries that use polygon bounding boxes produce wrong results.

For example, go to http://www.gbif.org/species/7303270 (genus of plants in New Guinea), zoom in one level on the map, then click "View records in viewable area" http://www.gbif.org/occurrence/search?TAXON_KEY=7303270&SPATIAL_ISSUES=false&GEOMETRY=-111+-60%2C-111+60%2C111+60%2C111+-60%2C-111+-60

Notice that the map shows no records, but there are 55 occurrences listed(!).

Reproduce using API with POLYGON((-111 60, 111 60, 111 -60, -111 -60, -111 60))

http://api.gbif.org/v0.9/occurrence/search?geometry=POLYGON%28%28-111%2060%2C%20111%2060%2C%20111%20-60%2C%20-111%20-60%2C%20-111%2060%29%29&taxonKey=7303270

API returns 55 records in a bounding box with no occurrences of this species!

I wonder whether the bounding box (which crosses latitude 0) is being misinterpreted?

Some bounding boxes that enclose New Guinea produce spurious results, e.g.  POLYGON((127 -13, 127 7, 155 7, 155 -13, 127 -13)) returns three records, all with 0,0 coordinates (which is not in the bounding box), and none of the records which are win the bounding box, see also http://www.gbif.org/occurrence/search?TAXON_KEY=7303270&SPATIAL_ISSUES=false&GEOMETRY=127+-13%2C127+7%2C155+7%2C155+-13%2C127+-13

Strangely, if I tweak the POLYGON so it is not square, e.g. POLYGON((127 -13, 120 7, 155 7, 155 -13, 127 -13)), then I get what look like the correct records.

By the way, I've made a v. crude tool http://bl.ocks.org/rdmpage/raw/d8bff65e1744916d44ba/ that enables you to paste in a WKT polygon and see it on a map, if you pick "view WKT for feature" and mouse over the polygon, the script will search for the corresponding occurrences in that regions (for http://www.gbif.org/species/7303270 ). It's a hack of some OpenLayer code I found somewhere.]]>
    

Author: rdmpage
Comment: Just noticed the edit location filter on portal, which enables editing bounding boxes, nice!
Created: 2014-06-22 22:18:00.213
Updated: 2014-06-22 22:18:00.213

Author: rdmpage
Created: 2014-06-22 22:29:00.338
Updated: 2014-06-22 22:29:00.338
        
OK, looks like part of problem is order of points in polygon.

For example, POLYGON((127 7, 127 -13, 155 -13, 155 7, 127 7)) works, but POLYGON((127 -13, 127 7, 155 7, 155 -13, 127 -13)) doesn't, even though they have same spatial extent.

The portal web site uses the ordering that seems to fail (MINX MINY is first point). If first point is (MINX MAXY) portal and API work.

Maybe need to check how polygons are interpreted, and how portal generates them. At the moment polygons that are "the same" are not interpreted the same, and API and portal don't match in how they encode polygons.