Regina is both right and wrong, I think.
Right, in that the spatial relationship functions are topological, and
are not "aware" of the coordinate system of the geometry that is passed
to them. They will always be valid for the topological relationship of
the inputs, but they *assume* that the inputs lie in a planar space, and
have straight lines between their vertices.
Wrong, in that this assumption of planarity and linear edges does not
hold for geometry which is defined in a non-planar coordinate system
(ie. geodetic). In this case the edges are not linear, they are arcs on
the spheroid. One result of this is what Markus pointed out - points
can "jump" from one side of an edge to another. Or more precisely, a
point which lies on one side of a linear edge between two vertices might
lie on the other side of the spheroidal arc between those two vertices.
This means that the spatial predicates do not always match the
relationship that holds on the spheroid (They do correctly provide the
true relationship in a planar space - but for a geodetic coordinate
system this is usually not what is expected).
There's no ideal way of correcting this. It can be mitigated somewhat
by densifying geodetic geometry before relating it, or by projecting to
a local planar coordinate system.
But, I think there is a bit of good news. I'm pretty sure that if you
are querying in lat-long space, relationships like ST_contains end up
being *more inclusive*. (I.e. you may get points returned which
wouldn't actually lie in the geometry if it was densified). This is due
to the fact that the spheroid "blows up like a balloon" and curves lines
outward. This is probably better than the alternative of being *less
inclusive*.
This also means that there is no problem using the standard PostGIS
spatial index on geodetic data - the index is only an approximation
anyway, so as long as it doesn't lose geometry (which it won't by the
argument above) it will work fine.
Of course, the other issue with handling geodetic data is dealing with
the poles and the 180th meridian. There's no great solution for this,
unfortunately. You can't query across the poles or dateline and expect
the query to "wrap around".
Martin
Obe, Regina wrote:
Will,
I could be way off base here because I don't think too much about
geometries except in my little world so maybe someone can correct me if
my assumptions are way off base.
Topological relations and processes like ST_Contains, ST_Intersection,
ST_Intersects are operations that are always valid regardless of if your
data is projected or unprojected.
If a contains b in WGS 84 long lat space, a will contain b in any
projection you can project them to (and vice versa). I think about
these things as just wrapping rubber bands around stuff. No matter how
you distort the shape of the rubber band, things inside it are always
inside it.
Now as far as indexes go - they wouldn't be as efficient in
non-projected space because a box in unprojected has less meaning (since
its a planar thing in spherical space). So your operation will work but
it will be slower since you'll get more false positives.
An extent will always contain the geometry in question regardless of
projection (although the extent of unprojected would be different from
if you had it in planar). Regardless - all objects contained within an
object should always have extents that intersect the extent of the
object that contains them in any space. So my thought process tells me,
you shouldn't get any points left out, you'll just get more false
positives from the && operation and thus slower performance.
So just keep your data in SRID 4326 do your contains in that and see
how slow it is. May not be all that slow.
Hope that helps,
Regina
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
William Temperley
Sent: Friday, June 27, 2008 4:49 AM
To: [email protected]
Subject: [postgis-users] ST_Contains - WGS84
Hi all
Is there currently an accurate way to run queries like ST_Contains on
geodetic data?
My dataset is global and I may have to perform queries on a
continental scale, e.g. find all the points in Africa. I don't think
I can reproject to the UTM zone in question, given the queries will
span several zones. Is there a projection I can use temporarily to
perform queries like this?
I'm also slightly worried that the planar nature of the spatial
indexes could prematurely remove points from the result set - is this
the case?
Will
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
