Thanks for the clarification. True intersects (ST_Intersects) or bounding box intersects (&&)?
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; http://wastac.ivec.org 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. ;-) On 12 May 2010 10:08, Paul Ramsey <pram...@opengeo.org> wrote: > On Tue, May 11, 2010 at 4:30 PM, Nicholas Bower <n...@petangent.net> > wrote: > > > > On 12 May 2010 08:14, Paul Ramsey <pram...@opengeo.org> wrote: > >> > >> The doc example appears to not mention the limitation in the geography > >> implementation, which can be fixed. The example is correct, insofar > >> as it is against geometries, but again, doesn't illustrate the > >> limitation in the geography implementation. > > > > I see that would explain it. So how do I actually determine if 1 > geography > > polygon is wholly inside another (on the WGS spheroid)? > > Right now you don't. You've got intersects on all types, but that's > it. I can provide a quote if you want to fund the work. > > Workarounds would including testing for index interaction in geography > land, then flipping both candidates out to a "suitable" projection for > a test in geometry land. See the ST_Buffer(geography) implementation > for an example of that approach. This would avoid the singularity > issues around the poles/dateline, but would fail for very large > (geographic size-wise) objects. > > P. > > > > >> > >> You can cast geography to geometry and use the function that way but > >> be forewarned about any shape that crosses the datesline/poles or has > >> very long edges. > > > > Not an option - this warning is precisely why I spent substantial effort > > migrating our DB out of 1.3 geometries into 1.5 geographies. We have > global > > satellite views that cross the IDL, and intersections of spatial regions > > nowhere near these shapes were previously returning true using geometries > > (wrapping the wrong way around the Earth). > > Am very grateful for geographies - just need a way to do the query with 2 > > polygons... > > > > > >> > >> On Tue, May 11, 2010 at 3:06 PM, Nick Bower <n...@petangent.net> wrote: > >> > Thanks but not according to the doc I think? > >> > 1) Abstract superclass is mentioned in API, not point, > >> > 2) the SQL example uses circles > >> > 3) the blog link specifically uses polygons in it's discussion of OGC > >> > coverage behaviour. > >> > > >> > > >> > > http://postgis.refractions.net/documentation/manual-1.5/ST_CoveredBy.html > >> > > >> > I'm not disputing your explanation given the evidence, but suggest the > >> > docs > >> > are entirely misleading for me figuring out if one polygon geography > is > >> > wholey inside another. > >> > > >> > > >> > On 11/05/2010, at 11:48 PM, Paul Ramsey <pram...@opengeo.org> wrote: > >> > > >> >> Bad sentence construction in the error, perhaps? The restriction > "only > >> >> polygon and point" means that one argument must be a polygon and one > >> >> must be a point. Both your arguments are polygons. > >> >> > >> >> P. > >> >> > >> >> On Tue, May 11, 2010 at 4:51 AM, Nicholas Bower <n...@petangent.net> > >> >> wrote: > >> >>> > >> >>> I've read the 1.5 reference docs but can't figure out what is wrong > >> >>> with > >> >>> below. ST_CoveredBy(geography, geography) should work right? > >> >>> select count(*) from t_swath_metadata where ST_CoveredBy( > >> >>> ST_GeogFromText('SRID=4326;POLYGON((123.1773295292851 > >> >>> -16.07501950971949, > >> >>> 122.745660066063 -16.83965661151543, > >> >>> 124.1310486688905 -16.44978157737539, > >> >>> 123.1773295292851 -16.07501950971949))'), > >> >>> swath_bounding); > >> >>> ERROR: geography_covers: only POLYGON and POINT types are currently > >> >>> supported > >> >>> CONTEXT: SQL function "st_covers" statement 1 > >> >>> ********** Error ********** > >> >>> ERROR: geography_covers: only POLYGON and POINT types are currently > >> >>> supported > >> >>> SQL state: XX000 > >> >>> Context: SQL function "st_covers" statement 1 > >> >>> > >> >>> db=> \d t_swath_metadata; > >> >>> ... > >> >>> swath_bounding | geography(Polygon,4326) | > >> >>> Indexes: > >> >>> ... > >> >>> "t_swath_metadata_swath_bounding_key" gist (swath_bounding) > >> >>> > >> >>> Thanks, Nick > >> >>> > >> >>> _______________________________________________ > >> >>> postgis-users mailing list > >> >>> postgis-users@postgis.refractions.net > >> >>> http://postgis.refractions.net/mailman/listinfo/postgis-users > >> >>> > >> >>> > >> >> _______________________________________________ > >> >> postgis-users mailing list > >> >> postgis-users@postgis.refractions.net > >> >> http://postgis.refractions.net/mailman/listinfo/postgis-users > >> > > >> > _______________________________________________ > >> > postgis-users mailing list > >> > postgis-users@postgis.refractions.net > >> > http://postgis.refractions.net/mailman/listinfo/postgis-users > >> > > >> _______________________________________________ > >> postgis-users mailing list > >> postgis-users@postgis.refractions.net > >> http://postgis.refractions.net/mailman/listinfo/postgis-users > > > > > > _______________________________________________ > > postgis-users mailing list > > postgis-users@postgis.refractions.net > > http://postgis.refractions.net/mailman/listinfo/postgis-users > > > > > _______________________________________________ > postgis-users mailing list > postgis-users@postgis.refractions.net > http://postgis.refractions.net/mailman/listinfo/postgis-users >
_______________________________________________ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users