Thank you Paul, You certainly are the expert, and I have learned a great deal from you posts, as well as the PostGIS book which sits on my desk with your introduction.
So I will hope you will excuse the chutzpah, but to me it feels like something is broken, and I don't think it is that hard to fix. What do you think about this as an improvement to ST_intersects: 1. Implement a "pre-pass" check for polygons that span the anti-meridian (180 longitude) (e.g. intersect with anti-meridian) 2. If there is intersection: a. Split the polygon into shards by the anti-meridian b. perform normal ST_Intersects of the shards against the other polygon (or shards) c. Boolean AND the results d. use short-circuit logic if any intersection results in false 3. If no intersection proceed as normal Notes: 1. I say something feels broken because I sense it in your article & there is no clue in the documentation about this. 2. The test #1 can be very low overhead (just checking if the all longitudes are positive, all negative or mixed (and short circuiting if there are any mixed which would indicate a span of the anti-meridian) 3. The case where there is a span of the anti-meridian will be rare (who has that much data in the pacific?) 4. Yes, the code for handling the shards is not very elegant, but that branch would not often be taken 5. Note that my geometry column of the database is GIST indexed and the Boston rectangle is still picking up the one in the pacific, so the bounding box optimization for indexed search seems to be not working so well. 6. ST_Within might have this same issue, but the same fix should work for it (symmetry is wonderful!). The reason I do not want to go to GEOGRAPHY types is that my application is using using a view-box (of a map) as the search box against a 20 Million record database of map objects (images, features, etc.) that are all represented as by rectangular bounding boxes. The PostGIS notes talk a lot about he overheard of GEOGRAPHY types, and it is overkill in this case. All I want to know is what is in the view-box - and rough estimates will work for that. - Yechezkal -- View this message in context: http://postgis.17.n6.nabble.com/Why-should-these-boxes-intersect-tp4998895p4998924.html Sent from the PostGIS - User mailing list archive at Nabble.com. _______________________________________________ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users