[postgis-users] Why should these boxes intersect?

[Paul Ramsey]

If you want to keep using geometry and still handle datelines/poles,
you'll have to scab in the catch-n-cut logic at the application layer.
You won't be alone, many others have done so, particularly in the days
before geography.

As Sandro notes, we have deliberately not tried to do automagical
solutions for geodetic data in geometry, feeling that being explicit
about behaviour (geometry is cartesian, geography is spherical) is
better. For simple bounding box work I doubt you'll find that
geography is horribly under-performing. And with the latest updates
you might find it works exceptionally well
(http://blog.opengeo.org/2012/07/12/making-geography-faster/)

P.

On Thu, Jul 12, 2012 at 7:55 AM, DrYSG <ygutfreund at draper.com> 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 at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users