Opened 13 years ago
Closed 11 years ago
#573 closed defect (fixed)
ST_Contains(geog, geog) gives wrong answer
|Reported by:||pramsey||Owned by:||pramsey|
create table gpoints (id integer, g geography); insert into gpoints values (1, 'POINT(-120.585938 55.195313)'), (2, 'POINT(116.367188 57.656250)'); select st_astext(g), st_covers('POLYGON((-128.3203125 61.171875, -103.7109375 -54.140625, 72.0703125 0.3515625, 134.296875 15.8203125, 17.2265625 71.3671875, -6.328125 75.5859375, -128.3203125 61.171875))'::geography,g) from gpoints; select st_astext(g), st_covers('POLYGON((-124.453125 64.6875, -127.6171875 -46.0546875, 51.6796875 -18.6328125, 46.0546875 -9.84375, 47.8125 17.2265625, 50.9765625 32.34375,-124.453125 64.6875))'::geography,g) from gpoints;
This appears to be similar to #562, where the point-in-polygon routine was failing because the generated "point outside" the polygon actually wasn't outside. In the second example, and outside point simply cannot be generated and everything stops.
I fear that as polygons get bigger, the question of what they "bound" comes into sharp relief in a way that is less problematic for small polygons. While most geodata is small enough to be obviously containing the "smaller" part of the sphere, it's trivially easy to generate a large polygon using a global mercator map in a GUI. Click, click, click, and you have a query polygon that visually covers most of the globe.
Change History (5)
comment:1 by , 13 years ago
comment:2 by , 13 years ago
Visualization of input polygon and candidate points
comment:3 by , 13 years ago
The improvement has removed the total failure from the second case. The answers may still be "wrong" depending on how you interpret the containment region of the polygon.
comment:4 by , 12 years ago
|Milestone:||PostGIS 1.5.3 → PostGIS 1.5.4|
comment:5 by , 11 years ago
|Status:||new → closed|
Nowhere to go from here.
Slight improvement in 1.5 at r5851, trunk at r5852