I'm trying to create a new instance on a different platform of a
postgis-enabled database, starting with just the schema definition. What's
the right way? This doesn't work below - do I have to partition into
separate schemas to have this work perhaps? Thanks, Nick
[Solaris Postgis 1.3.4] pg_du
s don't include it, and
> are often much smaller for it, which helps going between machines.
>
> cheers
>
> Ben
>
>
>
>
> On 09/04/2010, at 21:20 , Nicholas Bower wrote:
>
> > I'm trying to create a new instance on a different platform of a
> pos
On Mon, Apr 12, 2010 at 12:21 PM, Ben Madin
wrote:
> OK
>
> On 12/04/2010, at 10:03 , Nicholas Bower wrote:
>
> > 2. Dump just this separate data schema using pg_dump -Fc -N
>
> I think here you mean -n?, but it's six of one and half a dozen of the
> other. I rout
We have some tables in which we've used Geometry to store polygon and point
lan/lon (srid = -1). We embarked on this before PostGIS 1.5.x's spherical
Geography objects.
Now we intend to upgrade and migrate these to new Geography types (eg new
geography col, copy/convert, drop original geometry co
o: PostGIS Users Discussion
> Subject: Re: [postgis-users] Conversion from undefined geometry to
> geography?
>
> Just use geography(the_geom), it'll work fine. If you fine you have srid
> issues (I don't think you should) use
> geography(setsrid(the_geom,4326))
&g
7;t
> mind taking some extra risks, you can also
>
> set fsync=off;
>
> before you start and turn it back on when you're done.
>
> P
>
> On Tue, Apr 13, 2010 at 11:03 PM, Nicholas Bower
> wrote:
> > Ok thanks - so this is really my solution by the looks;
Just upgraded to PostGIS 1.5.1 on a windows XP machine (from 1.3.4) and when
creating an index on a geography column using this single statement;
CREATE INDEX t_swath_metadata_swath_bounding_key ON wastac.t_swath_metadata
USING gist (swath_bounding);
I get a client error
DEBUG: StartTransaction
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,
12
t; >
> >> 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.
> >>
>
th for not returning views of New Zealand in
searches of the Indian Ocean. ;-)
On 12 May 2010 10:08, Paul Ramsey wrote:
> On Tue, May 11, 2010 at 4:30 PM, Nicholas Bower
> wrote:
> >
> > On 12 May 2010 08:14, Paul Ramsey wrote:
> >>
> >> The doc example appea
Capture the start of the log and the first statement that fails. Below is
just repeating that there was an initial failure and it is not executing
more statements within this transaction. For example I've often found
aborts caused by inadequate permissions, in which case something like -u can be
Neither of the ST_Intersects clauses below invoke index usage according to
explain output, despite docs saying they should automatically be doing bbox
on the index;
explain analyze SELECT wastac.t_swath_metadata.swath_id AS
wastac_t_swath_metadata_swath_id
FROM wastac.t_swath_metadata
JOIN wast
On 25 May 2010 22:35, Mark Cave-Ayland wrote:
> Nicholas Bower wrote:
>
> Neither of the ST_Intersects clauses below invoke index usage according to
>> explain output, despite docs saying they should automatically be doing bbox
>> on the index;
>>
>
> (
01EFCC401F4B25C409F3BC1FEEB503FC0F8C610001C305D40B24CBF44BC613FC0'::geography)
Total runtime: 24.681 ms
On 25 May 2010 22:45, Nicholas Bower wrote:
>
>
> On 25 May 2010 22:35, Mark Cave-Ayland wrote:
>
>> Nicholas Bower wrote:
>>
>> Neither of the ST_Intersects
>
> What does the output of:
>
> SELECT version(), postgis_full_version();
>
> return?
>
PostgreSQL 8.4.3 on x86_64-pc-solaris2.10, compiled by GCC gcc (GCC) 3.4.3
(csl-sol210-3_4-branch+sol_rpath), 64-bit | POSTGIS="1.5.1"
GEOS="3.2.1-CAPI-1.6.1" PROJ="Rel. 4.7.1, 23 September 2009" LIBXML="2.6.2
> That does look like a pretty huge bounding polygon, but the geography we
> agree should still be using the spatial index, so probably making the index
> cost higher than it should
>
Fyi the border values are are simply composed of a regular 20km grid of
ajoining polygon squares covering Australi
ID=4326;POLYGON((116.751709 -31.381779,116.883545
> -32.676373,114.741211 -32.796510,114.796143-31.316101,116.751709
> -31.381779))'));
>
> Thanks
> Regina and Leo
> http://www.postgis.us
> --
> *From:* postgis-users-boun...@postgis.refractions.net [mailto:
> postgi
Well the index says it is being used, however I'm still quite suspicious
because of performance results below.
I attach 3 versions of a simply query (Geography ST_Intersects, Geometry
ST_Intersects, Geography &&) which is a simple square ROI intersection over
150k rows, each having a single polygo
t; > $$SELECT $1 && $2 AND _ST_Intersects(ST_Transform(geometry($1),
> > _ST_BestSRID($1)), ST_Transform(geometry($2), _ST_BestSRID($1)))$$
> > LANGUAGE 'sql' IMMUTABLE;
> >
> >
> >
> > From: postgis-users-b
query plan?
>
> FYI, it is not the index that is slower, it is the op. The index is
> actually (surprisingly) faster.
>
> P
>
>
>
> On May 31, 2010, at 5:06 PM, Nicholas Bower wrote:
>
> In the meantime perhaps someone could add a warning to the docs that
> geograp
20 matches
Mail list logo
