Thanks for the clarification. True intersects (ST_Intersects) or bounding box intersects (&&)?<div><br></div><div>I'll ask around and see if there is interest in funding something. Personally however I've been working with no secured funding on this for 3 years (not my day job) so can't fund myself sorry;</div>
<div><br></div><div><a href="http://wastac.ivec.org">http://wastac.ivec.org</a></div><div><br></div><div>The issue I think we have is that intersection of bounding boxes simply isn't very good for querying global space views from a small ROI as the views are quite pin cushioned as you would expect. Maybe it's just a compromise we have to live with for not returning views of New Zealand in searches of the Indian Ocean. ;-)</div>
<div><br></div><div><br><br><div class="gmail_quote">On 12 May 2010 10:08, Paul Ramsey <span dir="ltr"><<a href="mailto:pramsey@opengeo.org">pramsey@opengeo.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tue, May 11, 2010 at 4:30 PM, Nicholas Bower <<a href="mailto:nick@petangent.net">nick@petangent.net</a>> wrote:<br>
><br>
> On 12 May 2010 08:14, Paul Ramsey <<a href="mailto:pramsey@opengeo.org">pramsey@opengeo.org</a>> wrote:<br>
>><br>
>> The doc example appears to not mention the limitation in the geography<br>
>> implementation, which can be fixed. The example is correct, insofar<br>
>> as it is against geometries, but again, doesn't illustrate the<br>
>> limitation in the geography implementation.<br>
><br>
> I see that would explain it. So how do I actually determine if 1 geography<br>
> polygon is wholly inside another (on the WGS spheroid)?<br>
<br>
</div>Right now you don't. You've got intersects on all types, but that's<br>
it. I can provide a quote if you want to fund the work.<br>
<br>
Workarounds would including testing for index interaction in geography<br>
land, then flipping both candidates out to a "suitable" projection for<br>
a test in geometry land. See the ST_Buffer(geography) implementation<br>
for an example of that approach. This would avoid the singularity<br>
issues around the poles/dateline, but would fail for very large<br>
(geographic size-wise) objects.<br>
<font color="#888888"><br>
P.<br>
</font><div><div></div><div class="h5"><br>
<br>
<br>
>><br>
>> You can cast geography to geometry and use the function that way but<br>
>> be forewarned about any shape that crosses the datesline/poles or has<br>
>> very long edges.<br>
><br>
> Not an option - this warning is precisely why I spent substantial effort<br>
> migrating our DB out of 1.3 geometries into 1.5 geographies. We have global<br>
> satellite views that cross the IDL, and intersections of spatial regions<br>
> nowhere near these shapes were previously returning true using geometries<br>
> (wrapping the wrong way around the Earth).<br>
> Am very grateful for geographies - just need a way to do the query with 2<br>
> polygons...<br>
><br>
><br>
>><br>
>> On Tue, May 11, 2010 at 3:06 PM, Nick Bower <<a href="mailto:nick@petangent.net">nick@petangent.net</a>> wrote:<br>
>> > Thanks but not according to the doc I think?<br>
>> > 1) Abstract superclass is mentioned in API, not point,<br>
>> > 2) the SQL example uses circles<br>
>> > 3) the blog link specifically uses polygons in it's discussion of OGC<br>
>> > coverage behaviour.<br>
>> ><br>
>> ><br>
>> > <a href="http://postgis.refractions.net/documentation/manual-1.5/ST_CoveredBy.html" target="_blank">http://postgis.refractions.net/documentation/manual-1.5/ST_CoveredBy.html</a><br>
>> ><br>
>> > I'm not disputing your explanation given the evidence, but suggest the<br>
>> > docs<br>
>> > are entirely misleading for me figuring out if one polygon geography is<br>
>> > wholey inside another.<br>
>> ><br>
>> ><br>
>> > On 11/05/2010, at 11:48 PM, Paul Ramsey <<a href="mailto:pramsey@opengeo.org">pramsey@opengeo.org</a>> wrote:<br>
>> ><br>
>> >> Bad sentence construction in the error, perhaps? The restriction "only<br>
>> >> polygon and point" means that one argument must be a polygon and one<br>
>> >> must be a point. Both your arguments are polygons.<br>
>> >><br>
>> >> P.<br>
>> >><br>
>> >> On Tue, May 11, 2010 at 4:51 AM, Nicholas Bower <<a href="mailto:nick@petangent.net">nick@petangent.net</a>><br>
>> >> wrote:<br>
>> >>><br>
>> >>> I've read the 1.5 reference docs but can't figure out what is wrong<br>
>> >>> with<br>
>> >>> below. ST_CoveredBy(geography, geography) should work right?<br>
>> >>> select count(*) from t_swath_metadata where ST_CoveredBy(<br>
>> >>> ST_GeogFromText('SRID=4326;POLYGON((123.1773295292851<br>
>> >>> -16.07501950971949,<br>
>> >>> 122.745660066063 -16.83965661151543,<br>
>> >>> 124.1310486688905 -16.44978157737539,<br>
>> >>> 123.1773295292851 -16.07501950971949))'),<br>
>> >>> swath_bounding);<br>
>> >>> ERROR: geography_covers: only POLYGON and POINT types are currently<br>
>> >>> supported<br>
>> >>> CONTEXT: SQL function "st_covers" statement 1<br>
>> >>> ********** Error **********<br>
>> >>> ERROR: geography_covers: only POLYGON and POINT types are currently<br>
>> >>> supported<br>
>> >>> SQL state: XX000<br>
>> >>> Context: SQL function "st_covers" statement 1<br>
>> >>><br>
>> >>> db=> \d t_swath_metadata;<br>
>> >>> ...<br>
>> >>> swath_bounding | geography(Polygon,4326) |<br>
>> >>> Indexes:<br>
>> >>> ...<br>
>> >>> "t_swath_metadata_swath_bounding_key" gist (swath_bounding)<br>
>> >>><br>
>> >>> Thanks, Nick<br>
>> >>><br>
>> >>> _______________________________________________<br>
>> >>> postgis-users mailing list<br>
>> >>> <a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br>
>> >>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>
>> >>><br>
>> >>><br>
>> >> _______________________________________________<br>
>> >> postgis-users mailing list<br>
>> >> <a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br>
>> >> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>
>> ><br>
>> > _______________________________________________<br>
>> > postgis-users mailing list<br>
>> > <a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br>
>> > <a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>
>> ><br>
>> _______________________________________________<br>
>> postgis-users mailing list<br>
>> <a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br>
>> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>
><br>
><br>
> _______________________________________________<br>
> postgis-users mailing list<br>
> <a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br>
> <a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>
><br>
><br>
_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@postgis.refractions.net">postgis-users@postgis.refractions.net</a><br>
<a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-users</a><br>
</div></div></blockquote></div><br></div>