[postgis-users] st_dwithin
Hi, I have a database stored in WGS84 EPSG:4326 I would like ti find objects within a distance from a lat/lon point. 1) If i use 1 degree as the distance, will I then get an eliptic search area? 2) Will i find objects on the other side of the Datum shift border if I enter a point like lat=60°, lon= -179,5° with a distance of 1°? 3) Hov do I enter a lat/lon point and a distance in meters? Thanks, Paul ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Extract points from multipoint geometries
On Mon, May 10, 2010 at 11:32:32AM -0400, Charles Galpin wrote: ST_PointN doesn't work for multipoints, ST_GeometryN does. --strk; () Free GIS Flash consultant/developer /\ http://strk.keybit.net/services.html ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] ST_CoveredBy supporting geography?
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
Re: [postgis-users] st_dwithin
On 11 May 2010 07:34, Malm Paul paul.m...@saabgroup.com wrote: Hi, I have a database stored in WGS84 EPSG:4326 I would like ti find objects within a distance from a lat/lon point. 1) If i use 1 degree as the distance, will I then get an eliptic search area? 2) Will i find objects on the other side of the Datum shift border if I enter a point like lat=60°, lon= -179,5° with a distance of 1°? 3) Hov do I enter a lat/lon point and a distance in meters? If you want to do something that works but is relatively inefficient for 3, you can do the following: ST_DWithin() AND ST_DistanceSphere() distance in meters Of course, you would have to make sure that the search radius is big enough to correspond to your search in meters. Of course, it works only for points due to ST_DistanceSphere. If you want to perform something with any geometry, look at postgis 1.5 and the new geography type. Emilie Laffray ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Extract points from multipoint geometries
Even better, thanks! On May 11, 2010, at 3:15 AM, strk wrote: On Mon, May 10, 2010 at 11:32:32AM -0400, Charles Galpin wrote: ST_PointN doesn't work for multipoints, ST_GeometryN does. --strk; () Free GIS Flash consultant/developer /\ http://strk.keybit.net/services.html ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] ST_CoveredBy supporting geography?
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
Re: [postgis-users] st_dwithin
Would something like this be inefficient? I store data in a geometry
type, as I don't really care about the spheroid accuracy, as my
location queries are mostly less than 30 km apart. So...
SELECT ST_AsGeoJSON(location), title, description
FROM event
WHERE ST_DWithin(location::geography,
ST_GeogFromText('POINT(-83.359752 42.5212687)'),4000)
ORDER BY ST_Distance(location,
ST_GeomFromText('SRID=4326;POINT(-83.359752 42.5212687)'))
I cast geom to geog and perform st_dwithin and order by proximity.
Ilya
On Tue, May 11, 2010 at 8:37 AM, Emilie Laffray
emilie.laff...@gmail.com wrote:
On 11 May 2010 07:34, Malm Paul paul.m...@saabgroup.com wrote:
Hi,
I have a database stored in WGS84 EPSG:4326
I would like ti find objects within a distance from a lat/lon point.
1) If i use 1 degree as the distance, will I then get an eliptic search
area?
2) Will i find objects on the other side of the Datum shift border if I
enter a point like lat=60°, lon= -179,5° with a distance of 1°?
3) Hov do I enter a lat/lon point and a distance in meters?
If you want to do something that works but is relatively inefficient for 3,
you can do the following:
ST_DWithin() AND ST_DistanceSphere() distance in meters
Of course, you would have to make sure that the search radius is big enough
to correspond to your search in meters. Of course, it works only for points
due to ST_DistanceSphere.
If you want to perform something with any geometry, look at postgis 1.5 and
the new geography type.
Emilie Laffray
___
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] WKT expected, EWKT provided
Hello, I am getting the following error during database queries: WARNING:OGC WKT expected, EWKT provided - use GeomFromEWKT() for this I found some references to this using Google, so it appears to be a known item. I have tried wrapping all of my text geometries in 'GeomFromEWKT()' to no avail. How many dimensions is postgis WKT now expecting for 'POLYGON'? From where is this warning emitted? (ie: part of what library ) Thanks, P Ps. I thought to search your mailing list archives but they don't appear to be search-able. Is there any way to search the mail list archives other than by downloading every compressed file and using zcat and fgrep ? ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] WKT expected, EWKT provided
On 11 May 2010 12:04, Peter Willis pwil...@aslenv.com wrote: How many dimensions is postgis WKT now expecting for 'POLYGON'? OGC WKT has only 2 dimensions while EWKT has up to 4. Ps. I thought to search your mailing list archives but they don't appear to be search-able. Is there any way to search the mail list archives other than by downloading every compressed file and using zcat and fgrep ? You'd think it should be easy to do: http://postgis.refractions.net/pipermail/postgis-users/2008-December/022098.html -Mike ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] WKT expected, EWKT provided
Mike Toews wrote: On 11 May 2010 12:04, Peter Willis pwil...@aslenv.com wrote: How many dimensions is postgis WKT now expecting for 'POLYGON'? OGC WKT has only 2 dimensions while EWKT has up to 4. Ps. I thought to search your mailing list archives but they don't appear to be search-able. Is there any way to search the mail list archives other than by downloading every compressed file and using zcat and fgrep ? You'd think it should be easy to do: http://postgis.refractions.net/pipermail/postgis-users/2008-December/022098.html -Mike Hi Mike, Thanks for the location of the mail list search. (I must be blind sigh!) I am entering 2D polygons so from where would postgis be warning about EWKT entry? The error must be internal to the postgresql library module. Is this a versioning problem between sub-libraries of postgis? P ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] ST_CoveredBy supporting geography?
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
Re: [postgis-users] ST_CoveredBy supporting geography?
Nick,
Hmm, I guess we didn't provide a geography example and also didn't put in
the restrictions for geography. We'll update the docs.
For geometry -- ST_CoveredBy covers Polygon/polygon and various other
permutations.
The geography version is much more limited and as Paul mentioned only covers
Polygon /POINT
Hope that helps,
Regina
http://www.postgis.us
-Original Message-
From: postgis-users-boun...@postgis.refractions.net
[mailto:postgis-users-boun...@postgis.refractions.net] On Behalf Of Nick
Bower
Sent: Tuesday, May 11, 2010 6:06 PM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] ST_CoveredBy supporting geography?
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
Re: [postgis-users] ST_CoveredBy supporting geography?
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)?
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
Re: [postgis-users] ST_CoveredBy supporting geography?
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
Re: [postgis-users] ST_CoveredBy supporting geography?
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
Re: [postgis-users] ST_CoveredBy supporting geography?
Bounding box intersects () on geography will return
sane-on-the-spheroid results, which then can be reprojected for use in
geometry land.
On Tue, May 11, 2010 at 5:47 PM, Nicholas Bower n...@petangent.net wrote:
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;
NP. If you don't mind ticketing polygon-on-polyton covers in
geography, that would be great. On thinking on it, I'm not sure why I
didn't implement it in first pass. Maybe I just ran out of time.
P.
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] Cannot install postgis 1.5.1 on Postgres 9.0 beta1
Hi, Postgis 1.5.1 compiles ok on Postgres 9.0 beta1, but when I run make install it fails: ... PostGIS was built successfully. Ready to install. make -C postgis install make[1]: Entering directory `/home/japearson/postgis/postgis-1.5.1/postgis' Makefile.pgxs:17: warning: overriding commands for target `install' /usr/pgsql-9.0/lib/pgxs/src/makefiles/pgxs.mk:100: warning: ignoring old commands for target `install' Makefile.pgxs:63: warning: overriding commands for target `installdirs' /usr/pgsql-9.0/lib/pgxs/src/makefiles/pgxs.mk:148: warning: ignoring old commands for target `installdirs' Makefile.pgxs:82: warning: overriding commands for target `uninstall' /usr/pgsql-9.0/lib/pgxs/src/makefiles/pgxs.mk:172: warning: ignoring old commands for target `uninstall' /bin/mkdir -p '/usr/pgsql-9.0/lib' '/usr/pgsql-9.0/share/contrib/postgis-1.5' make[1]: /usr/pgsql-9.0/share/contrib/postgis-1.5: Command not found make[1]: *** [installdirs] Error 127 make[1]: Leaving directory `/home/japearson/postgis/postgis-1.5.1/postgis' make: *** [postgis-install] Error 2 Any ideas? Is postgis simply incompatible with Postgres 9.0beta at the moment? Cheers, -Joel -- Joel Pearson Software Engineer Agile Digital Engineering Pty Ltd A.B.N. 98 106 361 273 A: 5/28 Eyre St Kingston ACT 2604 P: +61 1300-858-277 F: +61 1300-858-477 M: +61 (0) 405-417-843 E: joel.pear...@agiledigital.com.au W: http://www.agiledigital.com.au ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Cannot install postgis 1.5.1 on Postgres 9.0 beta1
Joel, Which OS are you building under? We tried under Windows and had other issues, but assumed it was just a windows mingW issue. Last we tried compiling at the 8.5lahpa something or other, we were able to compile and install as I recall. That was a while ago though. Thanks, Leo and Regina _ From: postgis-users-boun...@postgis.refractions.net [mailto:postgis-users-boun...@postgis.refractions.net] On Behalf Of Joel Pearson Sent: Tuesday, May 11, 2010 9:14 PM To: postgis-users@postgis.refractions.net Subject: [postgis-users] Cannot install postgis 1.5.1 on Postgres 9.0 beta1 Hi, Postgis 1.5.1 compiles ok on Postgres 9.0 beta1, but when I run make install it fails: ... PostGIS was built successfully. Ready to install. make -C postgis install make[1]: Entering directory `/home/japearson/postgis/postgis-1.5.1/postgis' Makefile.pgxs:17: warning: overriding commands for target `install' /usr/pgsql-9.0/lib/pgxs/src/makefiles/pgxs.mk:100: warning: ignoring old commands for target `install' Makefile.pgxs:63: warning: overriding commands for target `installdirs' /usr/pgsql-9.0/lib/pgxs/src/makefiles/pgxs.mk:148: warning: ignoring old commands for target `installdirs' Makefile.pgxs:82: warning: overriding commands for target `uninstall' /usr/pgsql-9.0/lib/pgxs/src/makefiles/pgxs.mk:172: warning: ignoring old commands for target `uninstall' /bin/mkdir -p '/usr/pgsql-9.0/lib' '/usr/pgsql-9.0/share/contrib/postgis-1.5' make[1]: /usr/pgsql-9.0/share/contrib/postgis-1.5: Command not found make[1]: *** [installdirs] Error 127 make[1]: Leaving directory `/home/japearson/postgis/postgis-1.5.1/postgis' make: *** [postgis-install] Error 2 Any ideas? Is postgis simply incompatible with Postgres 9.0beta at the moment? Cheers, -Joel -- Joel Pearson Software Engineer Agile Digital Engineering Pty Ltd A.B.N. 98 106 361 273 A: 5/28 Eyre St Kingston ACT 2604 P: +61 1300-858-277 F: +61 1300-858-477 M: +61 (0) 405-417-843 E: joel.pear...@agiledigital.com.au W: http://www.agiledigital.com.au ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Cannot install postgis 1.5.1 on Postgres 9.0 beta1
Hi, I am building under Centos 5.4 I was building with geos 3.2.2 and proj 4.7.0 Cheers, -Joel ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Cannot install postgis 1.5.1 on Postgres 9.0 beta1
No, seems to compile and install perfectly fine under OS/X. Two regression failures (*sigh*) due to a slight change in output from SQL (select queries that don't return rows now return 'SELECT number of rows' instead of just 'SELECT') P. On Tue, May 11, 2010 at 6:13 PM, Joel Pearson japear...@agiledigital.com.au wrote: Hi, Postgis 1.5.1 compiles ok on Postgres 9.0 beta1, but when I run make install it fails: ... PostGIS was built successfully. Ready to install. make -C postgis install make[1]: Entering directory `/home/japearson/postgis/postgis-1.5.1/postgis' Makefile.pgxs:17: warning: overriding commands for target `install' /usr/pgsql-9.0/lib/pgxs/src/makefiles/pgxs.mk:100: warning: ignoring old commands for target `install' Makefile.pgxs:63: warning: overriding commands for target `installdirs' /usr/pgsql-9.0/lib/pgxs/src/makefiles/pgxs.mk:148: warning: ignoring old commands for target `installdirs' Makefile.pgxs:82: warning: overriding commands for target `uninstall' /usr/pgsql-9.0/lib/pgxs/src/makefiles/pgxs.mk:172: warning: ignoring old commands for target `uninstall' /bin/mkdir -p '/usr/pgsql-9.0/lib' '/usr/pgsql-9.0/share/contrib/postgis-1.5' make[1]: /usr/pgsql-9.0/share/contrib/postgis-1.5: Command not found make[1]: *** [installdirs] Error 127 make[1]: Leaving directory `/home/japearson/postgis/postgis-1.5.1/postgis' make: *** [postgis-install] Error 2 Any ideas? Is postgis simply incompatible with Postgres 9.0beta at the moment? Cheers, -Joel -- Joel Pearson Software Engineer Agile Digital Engineering Pty Ltd A.B.N. 98 106 361 273 A: 5/28 Eyre St Kingston ACT 2604 P: +61 1300-858-277 F: +61 1300-858-477 M: +61 (0) 405-417-843 E: joel.pear...@agiledigital.com.au W: http://www.agiledigital.com.au ___ 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
Re: [postgis-users] Cannot install postgis 1.5.1 on Postgres 9.0 beta1
Hmm weird. As a sanity check, I compiled postgis 1.3.6 against 8.4 and it compiled fine. I then tried compile postgis 1.5.1 and it failed with this error: /bin/sh /usr/lib/pgsql/pgxs/src/makefiles/../../config/install-sh -c pgsql2shp /var/tmp/postgis-1.5.1-2-root-japearson/usr/bin /bin/sh /usr/lib/pgsql/pgxs/src/makefiles/../../config/install-sh -c shp2pgsql /var/tmp/postgis-1.5.1-2-root-japearson/usr/bin make[1]: Leaving directory `/home/japearson/rpmbuild/BUILD/postgis-1.5.1/loader' + install -d /var/tmp/postgis-1.5.1-2-root-japearson/usr/lib/pgsql/ + install 'lwgeom/liblwgeom.so*' /var/tmp/postgis-1.5.1-2-root-japearson/usr/lib/pgsql/ install: cannot stat `lwgeom/liblwgeom.so*': No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.56429 (%install) So I'm guessing that there is something wrong with my setup. So if I can get postgis 1.5.1 to compile against postgres 8.4.3 then 9 beta1 may work as well. Cheers, -Joel On 12 May 2010 14:32, Paul Ramsey pram...@opengeo.org wrote: No, seems to compile and install perfectly fine under OS/X. Two regression failures (*sigh*) due to a slight change in output from SQL (select queries that don't return rows now return 'SELECT number of rows' instead of just 'SELECT') P. On Tue, May 11, 2010 at 6:13 PM, Joel Pearson japear...@agiledigital.com.au wrote: Hi, Postgis 1.5.1 compiles ok on Postgres 9.0 beta1, but when I run make install it fails: ... PostGIS was built successfully. Ready to install. make -C postgis install make[1]: Entering directory `/home/japearson/postgis/postgis-1.5.1/postgis' Makefile.pgxs:17: warning: overriding commands for target `install' /usr/pgsql-9.0/lib/pgxs/src/makefiles/pgxs.mk:100: warning: ignoring old commands for target `install' Makefile.pgxs:63: warning: overriding commands for target `installdirs' /usr/pgsql-9.0/lib/pgxs/src/makefiles/pgxs.mk:148: warning: ignoring old commands for target `installdirs' Makefile.pgxs:82: warning: overriding commands for target `uninstall' /usr/pgsql-9.0/lib/pgxs/src/makefiles/pgxs.mk:172: warning: ignoring old commands for target `uninstall' /bin/mkdir -p '/usr/pgsql-9.0/lib' '/usr/pgsql-9.0/share/contrib/postgis-1.5' make[1]: /usr/pgsql-9.0/share/contrib/postgis-1.5: Command not found make[1]: *** [installdirs] Error 127 make[1]: Leaving directory `/home/japearson/postgis/postgis-1.5.1/postgis' make: *** [postgis-install] Error 2 Any ideas? Is postgis simply incompatible with Postgres 9.0beta at the moment? Cheers, -Joel -- Joel Pearson Software Engineer Agile Digital Engineering Pty Ltd A.B.N. 98 106 361 273 A: 5/28 Eyre St Kingston ACT 2604 P: +61 1300-858-277 F: +61 1300-858-477 M: +61 (0) 405-417-843 E: joel.pear...@agiledigital.com.au W: http://www.agiledigital.com.au ___ 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 -- Joel Pearson Software Engineer Agile Digital Engineering Pty Ltd A.B.N. 98 106 361 273 A: 5/28 Eyre St Kingston ACT 2604 P: +61 1300-858-277 F: +61 1300-858-477 M: +61 (0) 405-417-843 E: joel.pear...@agiledigital.com.au W: http://www.agiledigital.com.au ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] PostgreSQL 9.0 beta1 PostGIS 1.5 for Windows
We've got a successful build now for 1.5 SVN against PostgreSQL 9.0 beta 1 for Windows (well 32-bit anyway). We'll try to release an experimental package for windows sometime this week that includes 9.0 beta1. As far as putting on stack builder, we are going to wait till PostGIS 1.5.2 is officially released and put out 8.3,8.4, 9.0 . I think we are due for a release in the next month or so. Thanks, Leo and Regina http://www.postgis.us ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
