Support for larger objects in ST_Intersection(geography)

[realityexists]

Please enhance ST_Intersection(geography) and ST_Intersects(geography) to handle larger shapes than they currently support and shapes touching the poles by internally transforming to a Gnomic projection as necessary. A simple test case:

WITH data AS
(
    SELECT ST_GeogFromText('POLYGON((170 50,170 72,-130 72,-130 50,170 50))') AS poly1,
        ST_GeogFromText('POLYGON((-170 68,-170 90,-141 90,-141 68,-170 68))') AS poly2
)
SELECT ST_AsText(ST_Intersection(poly1, poly2))
FROM data

Expected result: POLYGON((-170 74.053793645338,-141 73.4268621378904,-141 68,-170 68,-170 74.053793645338))

Current result: POLYGON((-130 58.1309106133234,-130 65.0979231965232,-86.8913306802836 49.9999999999887,-104.762597274101 49.9999999999887,-130 58.1309106133234))

[pramsey]

In order to get 2.0 out, this is going to have to be deferred to 2.1.

[realityexists]

Another test case:

SELECT ST_Intersects('LINESTRING(-176 52,178 53)'::geography, 'LINESTRING(-176.3 52,-176.1 52.1)'::geography),
	ST_AsText(ST_Intersection('LINESTRING(-176 52,178 53)'::geography, 'LINESTRING(-176.3 52,-176.1 52.1)'::geography))

ST_Intersects returns true here (as of 2.0.0 release), but ST_Intersection returns GEOMETRYCOLLECTION EMPTY.

[pramsey]

There's two things I'm thinking about here.

• First, the internal code for finding bestsrid currently does nothing over the dateline. Both of these examples cross.
• Second, the use of Gnomic would be good for constructive geometry (since line crossings are exactly where they should be), but limiting for anything involving measurement, since it distorts area and distance rather quickly.

No easy answers, but topics of interest.

[pramsey]

crossing the dateline is now handled and the gnomic zones are added for mid-sized features at r10038