INTERSECTS – am I just doing something wrong or is there a bug?

[thisisaaronland]

Hi,

First: Tile38 is full of good! Meanwhile, we are investigating using it for spatial queries with the Who's On First project. We've been indexing data using this:

https://github.com/whosonfirst/go-whosonfirst-tile38/blob/master/index/index.go

And everything seems fine and good when doing NEARBY queries. When doing INTERSECTS queries though, things start to get weird. Specifically: Things that I would expect to return results because they intersect don't. For example:

127.0.0.1:9851> GET whosonfirst 85922583#whosonfirst-data
{"ok":true,"object":{"type":"Polygon","coordinates":[[[-123.173825,37.63983],[-123.173825,37.929824],[-122.28178,37.929824],[-122.28178,37.63983],[-123.173825,37.63983]]]},"elapsed":"115.752µs"}

127.0.0.1:9851> INTERSECTS whosonfirst BOUNDS 37.685451 -122.561417 37.881899 -122.23114
{"ok":true,"fields":["wof:id","wof:placetype_id"],"objects":[],"count":0,"cursor":0,"elapsed":"54.594µs"}

I can replicate this for both records that are indexed as MultiPolygons (under v1.5.1) and as bounding boxes (under a past version that reports itself as 0.0.0). I double-checked that each geometry is in fact intersected by the BOUNDS query (see attached GeoJSON files and screenshots) so I am at a bit of a loss.

Am I missing something obvious or is there a bug in here somewhere? The weirdest part for me is that I could swear I had all of this working as expected under an older version of Tile38, about a month ago...

The pink box is the INTERSECTS query and the grey boxes are the things indexed in Tile38

tile38-intersects-bbox.geojson.txt
tile38-intersects-poly.geojson.txt

Related:

https://whosonfirst.mapzen.com/spelunker/id/85922583/
https://whosonfirst.mapzen.com/data/859/225/83/85922583.geojson

[tidwall]

I am super sorry. I can confirm that there's been a regression between 1.4.2 and 1.5.0.

I'm investigating now. Rolling back to 1.4.2 seems to correct this issue.

Something broke between 46072f6 and 8270d11

[thisisaaronland]

Okay! That's good to know and we can rollback until a fix is in place. Will an AOF file created with 1.5.1 still work with 1.4.2 ?

[tidwall]

I added the [NX|XX] expiration keywords to the SET command. If you are not setting ttl expirations on keys then you should be ok. Otherwise I can whip up a 1.4.3 hotfix in the meantime.

[thisisaaronland]

Great. We are fine for now, then (not using TTL flags).

[tidwall]

Thanks so much for alerting me to this bug. I just pushed a new release 1.5.2 that addresses the problem. Please let me know if you run into any further issues.