PostGIS 2.0 geographic polygon has max longitudinal range

Question

My problem is that I have a load of geographic point data (srid 4326) in a table. A user may do a bounding box search - essentially create a polygon as follows:

l_poly geography(Polygon,4326):= 'POLYGON((-120 -89, -120 81, 59.999 81, 59.999 -20, -120 -20))';

... then query using the ST_Intersect predicate

WHERE ST_Intersects(my_tab.point_data, l_poly)

In the above example, I can return a point at lon=0, lat=0. However, once my eastern-most longitude goes above 60 degrees (currently 59.999), then the longitudinal range exceeds 180 degrees, and my polygon wraps the opposite way around the earth. In this case I can not return data at 0 longitude, but I would at e.g. 180 longitude.

It seems as though a geographic polygon cannot be defined that exceeds a longitudinal extent of 180 degrees. Is this true? Can anyone point me in the direction of a solution?

I have tried casting a geography from a geometry defined with enforced Right Handedness, which I thought might define the interior of the polygon to the right hand side of a clockwise drawn polygon. But this doesn't work either.

Answer 1

Densify your query polygon. Maybe ST_Segmentize()? Note that the lines between points are naturally going to be great circles, so if your users are drawing boxes on a mercator map, they could get back some results that look very odd to them (boxes you draw with straight lines in mercator will be interpreted as curvey great circles). A "solution" is to ST_Segmentize() sufficiently aggressively that the wee great circle edges coming out have very little curve to them.

Answer 2

Can't remember asking this question, but I've stumbled upon it 18 months later and realise I can add an explanation (at least of what I think happens):

PostGIS does not care how you order your points in a geographic (srid 4326) polygon. It is simply an array of points.

My original thoughts were about longitudinal range. In fact, it's not that. It's surface area. Write a simple loop that builds a bbox centred on a point, where the east and west progressively diverged in longitude and the north and south progressively diverged in latitude, for each iteration of the loop. Now compute the area of each iteration...

The area increases to a maximum of half the surface area of the earth, after which is reduces. Visualise this on a sphere rather than a mercator projection. When the polygon is as big as it can be, it divides the earth into 2 hemispheres and it is not unique which hemisphere is being defined. In fact PostGIS throws an error in this case (the exact hemisphere) when trying to compute area. As the x,y s 'diverge' further, in fact they are getting closer on the 'other side of the earth'. PostGIS can only guess which side of the earth you define by your polygon, and so guess the smaller area.

Until PostGIS implement a handedness e.g. a right hand rule, then an array of clockwise points and an array of anti-clockwise points are no different.

As an aside, as I was only bothered by constant lat and lon boxes, I was able to index the st_x and st_y of the point, and construct a bbox query that referenced these coordinates directly rather than using the spatial index.