[postgis-users] Why should these boxes intersect?

[Sandro Santilli]

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 at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users