geography && large_bbox fails

[strk]

I was looking at this case: ​https://hub.qgis.org/issues/8572 and tried to workaround by following the reccomendation of the exception message

Antipodal (180 degrees long) edge (180 -90,180 90) detected,
add a point between to make two edges that span less than 180 degrees.)

But doing so gave a false result:

strk=# with params as ( select st_makeenvelope(-180,-90,180,90,4326) as env, 'POINT(0 0)'::geography as g ) SELECT st_area(st_segmentize(env,170)), st_area(env) from params;
 st_area | st_area 
---------+---------
   64800 |   64800
(1 row)

strk=# with params as ( select st_makeenvelope(-180,-90,180,90,4326) as env, 'POINT(0 0)'::geography as g ) SELECT g && st_segmentize(env,170) from params;
 ?column? 
----------
 f
(1 row)

What am I missing, Paul ?

[pramsey]

Welllll... I'm not sure segmentize or your other calculations are doing what you think, since you're calling it within the context of geometry, not geography (note the areas you are returning, those are areas in degrees, not square meters), BUT, that's not the real problem.

The real problem is this idea that (-180, -90, 180, 90) is a "box". The "line" from -180,90 to 180,90 is not a line at all, there's no there there, it's just a point. Similarly at the bottom. So you aren't creating much of a bounding area, even if you did segmentize it.

This is a problem that SQL Server solved with a custom "everything" representation for geographies, so handle the "whole world" case.

The QGIS case is a flat world box being handed in and then we have an expectation for interpretation... probably the "right" thing to do is to segmentize it in geometry (as you have done, though far more aggressively (at 0.1 or 0.5 degrees), so that it more closely approximates on the globe what it is representing on the plane) then cast is into geography for processing. It should work better then. That still would fail for the "whole world" case, but would work right for most other "most of the world" cases.

For the whole world, I'm still not sure what to do.

[strk]

But even with somewhat smaller box, segmentized in geometry space, I still get a false ?

with params as ( 
 select st_makeenvelope(-170,-80,170,80,4326) as env, 'POINT(0 0)'::geography as g 
) SELECT g && st_segmentize(env::geometry,0.1) from params;

Thinking about it, I actually don't see why segmentize should make any difference as we're doing a bbox-only operation... uhm. Is there any way we can determine the direction of the box ? I mean, couldn't we interpret -180..180 differently than 180..-180 ? The former would be 360 degrees, the latter would be 0 degrees.

[strk]

We'd be basically assuming that the box coordinates would always be expressed so that you have to walk from "min" to "max" facing the sunshine (horizontally) and heading north (vertically)

[strk]

I've added some debugging lines but cannot understand what I'm seeing:

pg22=# with params as ( select st_makeenvelope(-170,-80,170,80,4326) as env, 'POINT(0 0)'::geography as g ) SELECT g && st_segmentize(env::geometry,0.1) from params;
NOTICE:  Boxes have dims 3 and 3
NOTICE:   0 - MIN(a):1 MAX(a):1
NOTICE:   0 - MIN(b):-1 MAX(b):0.173648
 ?column?
----------
 f
(1 row)

Where do those numbers (1,-1,0.173648) come from ?

[strk]

A 181 degrees wide box is enough to confuse geography_overlaps:

pg22=# select geography_overlaps( ST_MakeEnvelope(-90,-1,91,1,4326), 'POINT(0 1)' );
 geography_overlaps 
--------------------
 f
(1 row)

180 is good:

pg22=# select geography_overlaps( ST_MakeEnvelope(-90,-1,90,1,4326), 'POINT(0 1)' );
 geography_overlaps 
--------------------
 f
(1 row)

[strk]

Sorry, paste bug, 180 is good:

pg22=# select geography_overlaps( ST_MakeEnvelope(-90,-1,90,1,4326), 'POINT(0 1)' );
 geography_overlaps 
--------------------
 t
(1 row)

[pramsey]

Geography bounding boxes are constructed in geocentric space (x/y/z) from objects inscribed on a unit sphere using spherical coordinates (theta/phi). So, the north pole (0,90) in spherical coordinates is (0,0,1) in geocentric coordinates. This is one reason why geographic "bounding boxes" are hidden from end users: they'll never understand WTF is going on w/ them.

Your "181 degrees wide" box is not 181 degrees wide, there's no such thing, in a world where ever arc is defined as the "shortest route between two points". It's 179 degrees wide, across the opposite side of the world you expect. The overlaps result is correct. Similarly, the "180 degrees wide" box is not actually 180 degrees wide, since the shortest great circle connecting 90,1 to -90,1 has to run over longitude 0 (check it out). A truly 180 degree line would be from 90,0 to -90,0.

Trying to think about spherical geometry while looking at a mercator map is a recipe for a broken brain. Put a globe on your desk and get a piece of string.

[strk]

I understand the problem here is the "shortest route between two points" interpretation of every arc. How can we deal with that ? If the geometry was defined as many small arcs, would the result then be different ? As a bbox is _forced_ to only have 4 arcs, could we account for order expressing direction ?

[pramsey]

If the geometry was made of small arcs then yes the result would be different. It might still be *wrong* from a visual/user point of view, if the user is drawing straight lines on a flat map, since the small lines would still be great circles and wouldn't necessarily be isomorphic to the lines the user is seeing on her screen.

You'll have to be careful of your terminology when talking about "bounding boxes" in geography. The core bounding box, the one used for the index operators, is a bounding volume in geocentric space. You are perhaps talking about a 2d box drawn on a flat map, which isn't going to map easily 1:1 to a geographic shape, for the reasons noted in the previous paragraph.

You might find it useful to plug your boxes into the great circle mapper web site to get a feel for their "real world" implications in great circle land. ​http://www.gcmap.com/