Yechezkal, the reason why your solution isn't taken is because it assumes that the geometry is expressed in long/lat. This isn't always the case. The semantic of units, and thus the value of the anti-meridian (if any) depends on the spatial reference system.
The GEOGRAPHY type was introduced specifically for this: add knowledge about the earth shape. In GEOMETRY semantic, a box with minx > maxx would be just wrong. We choose to swap rather than throw an exception. Such choice could be debatable. --strk; ,------o-. | __/ | Delivering high quality PostGIS 2.1 | / 2.1 | http://strk.keybit.net - http://vizzuality.com `-o------' On Thu, Jul 12, 2012 at 07:55:27AM -0700, DrYSG wrote: > 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 _______________________________________________ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users