Thu, Feb 9 2006
20:11:13
|
|
Request created by guest
|
|
Subject: grass and postgis issue
Platform: Mac OSX
grass obtained from: Trento Italy site
grass binary for platform: Compiled from Sources
GRASS Version: cvs 2006
I am working with postgis tables and GRASS and have found what may be a bug.
If I try and read a postgis table (with geometry columns and spatial indexing
into GRASS, I get a new
vector but the associated postgis table has no geometry or spatial indexing.
For exmaple:
postgis output from Tyler Ms postgis example in "Web Mapping":
project1=# \d countyp020
Table "public.countyp020"
Column | Type | Modifiers
------------+-----------------------
+----------------------------------------------------------
gid | integer | not null default nextval('countyp020_gid_seq'::regclass)
area | double precision |
perimeter | double precision |
countyp020 | bigint |
state | character varying(2) |
county | character varying(50) |
fips | character varying(5) |
state_fips | character varying(2) |
square_mil | double precision |
the_geom | geometry |
Indexes:
"countyp020_pkey" PRIMARY KEY, btree (gid)
"idx_countyp020_geo" gist (the_geom)
"idx_countyp020_gid" btree (gid)
Check constraints:
"enforce_dims_the_geom" CHECK (ndims(the_geom) = 2)
"enforce_geotype_the_geom" CHECK (geometrytype(the_geom) = 'MULTIPOLYGON'::text
OR
the_geom IS NULL)
"enforce_srid_the_geom" CHECK (srid(the_geom) = -1)
However, reading the table back into GRASS with either pgsql2shp, then v.in.ogr
on the shapefile, or
directly into GRASS with v.in.ogr on the postgis table, results in a new postgis
table that looks like
this:
project1=# \d countyp020_postgis
Table "public.countyp020_postgis"
Column | Type | Modifiers
------------+------------------------+-----------
cat | integer |
gid | integer |
area | double precision |
perimeter | double precision |
countyp020 | integer |
state | character varying(255) |
county | character varying(255) |
fips | character varying(255) |
state_fips | character varying(255) |
square_mil | double precision |
Indexes:
"countyp020_postgis_cat" UNIQUE, btree (cat)
or:
project1=# \d countyp020_grass
Table "public.countyp020_grass"
Column | Type | Modifiers
------------+-----------------------+-----------
cat | integer |
area | double precision |
perimeter | double precision |
countyp020 | double precision |
state | character varying(2) |
county | character varying(50) |
fips | character varying(5) |
state_fips | character varying(2) |
square_mil | double precision |
Indexes:
"countyp020_grass_cat" UNIQUE, btree (cat)
Notice the lack of geometry and idexes in both posgis tables. Also, the difference
in type lengths
(character 5 vs 250 for fips).
Additionally, if I add the geometry and idexing in posgis (once it has been read
into GRASS and is
therefor connected to the GRASS vector with bd.connect, and then try and copy
or rename the vector
with g.copy or g.rename, I get the following error:
> g.rename vect=mn_btvegpt_byspp,mn_btvegpt
RENAME [mn_btvegpt_byspp] to [mn_btvegpt]
WARNING: pg driver: column 'the_geometry', type 16651 is not supported
WARNING: pg driver: column 'the_geometry', type 16651 is not supported
|
|
Thu, Feb 9 2006
20:59:17
|
|
Mail sent by mlennert@club.worldonline.be
|
|
Return-Path |
<mlennert@club.worldonline.be>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Message-ID |
<38537.85.10.65.247.1139515147.squirrel@geog-pc40.ulb.ac.be>
|
In-Reply-To |
<20060209191113.B81431005A4@lists.intevation.de>
|
References |
<20060209191113.B81431005A4@lists.intevation.de>
|
Date |
Thu, 9 Feb 2006 20:59:07 +0100 (CET)
|
Subject |
Re: [GRASS5] [bug #4075] (grass) grass and postgis issue
|
From |
"Moritz Lennert" <mlennert@club.worldonline.be>
|
To |
"Request Tracker" <grass-bugs@intevation.de>
|
Cc |
grass5@grass.itc.it
|
User-Agent |
SquirrelMail/1.4.5
|
MIME-Version |
1.0
|
Content-Type |
text/plain;charset=iso-8859-1
|
Content-Transfer-Encoding |
8bit
|
X-Priority |
3 (Normal)
|
Importance |
Normal
|
X-Spam-Status |
No, hits=-3.7 tagged_above=-999.0 required=3.0 tests=BAYES_00, PRIORITY_NO_NAME
|
X-Spam-Level |
|
On Thu, February 9, 2006 20:11, Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=4075
> -------------------------------------------------------------------------
>
> Subject: grass and postgis issue
>
> Platform: Mac OSX
> grass obtained from: Trento Italy site
> grass binary for platform: Compiled from Sources
> GRASS Version: cvs 2006
>
> I am working with postgis tables and GRASS and have found what may be a
> bug.
>
> If I try and read a postgis table (with geometry columns and spatial
> indexing into GRASS, I get a new
> vector but the associated postgis table has no geometry or spatial
> indexing.
GRASS doesn't need the geometry since it is stored in the GRASS format, so
why should it keep this column. What is it you want to do exactly: import
a postgis map into GRASS, or view a postgis map with GRASS ? See
v.external it it is the latter.
As for indexing, this obviously first of all depends on the database
backend that you use for GRASS maps (e.g. the dbf backend wouldn't support
indexing). You seem to use postgresql as backend, so indexing would be
possible. However, most of the indexes are on the geometry column, so they
would not be needed for a map in GRASS format. Why do you want these
indexes ?
Moritz
> For exmaple:
>
> postgis output from Tyler Ms postgis example in "Web Mapping":
>
> project1=# \d countyp020
> Table "public.countyp020"
> Column | Type | Modifiers
> ------------+-----------------------
> +----------------------------------------------------------
> gid | integer | not null default
> nextval('countyp020_gid_seq'::regclass)
> area | double precision |
> perimeter | double precision |
> countyp020 | bigint |
> state | character varying(2) |
> county | character varying(50) |
> fips | character varying(5) |
> state_fips | character varying(2) |
> square_mil | double precision |
> the_geom | geometry |
> Indexes:
> "countyp020_pkey" PRIMARY KEY, btree (gid)
> "idx_countyp020_geo" gist (the_geom)
> "idx_countyp020_gid" btree (gid)
> Check constraints:
> "enforce_dims_the_geom" CHECK (ndims(the_geom) = 2)
> "enforce_geotype_the_geom" CHECK (geometrytype(the_geom) =
> 'MULTIPOLYGON'::text OR
> the_geom IS NULL)
> "enforce_srid_the_geom" CHECK (srid(the_geom) = -1)
>
> However, reading the table back into GRASS with either pgsql2shp, then
> v.in.ogr on the shapefile, or
> directly into GRASS with v.in.ogr on the postgis table, results in a new
> postgis table that looks like
> this:
>
> project1=# \d countyp020_postgis
> Table "public.countyp020_postgis"
> Column | Type | Modifiers
> ------------+------------------------+-----------
> cat | integer |
> gid | integer |
> area | double precision |
> perimeter | double precision |
> countyp020 | integer |
> state | character varying(255) |
> county | character varying(255) |
> fips | character varying(255) |
> state_fips | character varying(255) |
> square_mil | double precision |
> Indexes:
> "countyp020_postgis_cat" UNIQUE, btree (cat)
>
> or:
>
> project1=# \d countyp020_grass
> Table "public.countyp020_grass"
> Column | Type | Modifiers
> ------------+-----------------------+-----------
> cat | integer |
> area | double precision |
> perimeter | double precision |
> countyp020 | double precision |
> state | character varying(2) |
> county | character varying(50) |
> fips | character varying(5) |
> state_fips | character varying(2) |
> square_mil | double precision |
> Indexes:
> "countyp020_grass_cat" UNIQUE, btree (cat)
>
> Notice the lack of geometry and idexes in both posgis tables. Also, the
> difference in type lengths
> (character 5 vs 250 for fips).
>
> Additionally, if I add the geometry and idexing in posgis (once it has
> been read into GRASS and is
> therefor connected to the GRASS vector with bd.connect, and then try and
> copy or rename the vector
> with g.copy or g.rename, I get the following error:
>
>> g.rename vect=mn_btvegpt_byspp,mn_btvegpt
> RENAME [mn_btvegpt_byspp] to [mn_btvegpt]
> WARNING: pg driver: column 'the_geometry', type 16651 is not supported
> WARNING: pg driver: column 'the_geometry', type 16651 is not supported
>
>
> -------------------------------------------- Managed by Request Tracker
>
> _______________________________________________
> grass5 mailing list
> grass5@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>
|
|
Thu, Feb 9 2006
21:23:48
|
|
Mail sent by kwythers@umn.edu
|
|
Return-Path |
<kwythers@umn.edu>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
X-Umn-Remote-Mta |
[N] truffula.fr.umn.edu [128.101.74.69] #+LO+TS+AU+HN
|
In-Reply-To |
<38537.85.10.65.247.1139515147.squirrel@geog-pc40.ulb.ac.be>
|
References |
<20060209191113.B81431005A4@lists.intevation.de> <38537.85.10.65.247.1139515147.squirrel@geog-pc40.ulb.ac.be>
|
Mime-Version |
1.0 (Apple Message framework v746.2)
|
X-Priority |
3 (Normal)
|
Content-Type |
multipart/alternative; boundary=Apple-Mail-7-148141265
|
Message-Id |
<F73DD52F-15EE-4A32-859F-AB7904FEAF1B@umn.edu>
|
Cc |
"Request Tracker" <grass-bugs@intevation.de>, grass5@grass.itc.it
|
From |
"Kirk R. Wythers" <kwythers@umn.edu>
|
Subject |
Re: [GRASS5] [bug #4075] (grass) grass and postgis issue
|
Date |
Thu, 9 Feb 2006 14:23:34 -0600
|
To |
Moritz Lennert <mlennert@club.worldonline.be>
|
X-Mailer |
Apple Mail (2.746.2)
|
X-Spam-Status |
No, hits=-4.8 tagged_above=-999.0 required=3.0 tests=BAYES_00, HTML_MESSAGE
|
X-Spam-Level |
|
--Apple-Mail-7-148141265
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed
On Feb 9, 2006, at 1:59 PM, Moritz Lennert wrote:
> GRASS doesn't need the geometry since it is stored in the GRASS
> format, so
> why should it keep this column. What is it you want to do exactly:
> import
> a postgis map into GRASS, or view a postgis map with GRASS ? See
> v.external it it is the latter.
>
> As for indexing, this obviously first of all depends on the database
> backend that you use for GRASS maps (e.g. the dbf backend wouldn't
> support
> indexing). You seem to use postgresql as backend, so indexing would be
> possible. However, most of the indexes are on the geometry column,
> so they
> would not be needed for a map in GRASS format. Why do you want these
> indexes ?
>
>
> Moritz
Thanks for the reply Moritz. This all started out as a "can I speed
this querry up" exercise. Perhaps the fundamental issue is my not
completely understanding how GRASS makes use of the postgis extension
to postgresql. You are correct in that I am using psotgresql for
database management. I have an attribute table of little over a
million lines of data in a postgres table that is associated with a
grass vector. The table contains point data based on simple xy utm
coordinates.
This allows me to run a query like:
d.vect vector_name size=2 color=blue where="species='WP' AND diam>40"
I would guess that it takes d.vect about a minute to draw the results
of this query. I have never been able to quite figure out how GRASS
works with the postgis extension. All I was trying to do was speed
things up a bit, so I added the postgis geometry and spatial indexing
to the posgresql table. When I discovered that GRASS then didn't
behave as I expected (g.copy, g.rename), I thought that there were
three possible explanations: 1. a bug, 2. I didn't have postgis
configured properly, 3. (most likely) user error, or user not
understanding how something was supposed to work.
Any enlightenment in that last area is much appreciated.
Kirk
--Apple-Mail-7-148141265
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=ISO-8859-1
<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><BR><DIV><DIV>On Feb 9, 2006, at =
1:59 PM, Moritz Lennert wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">GRASS doesn't need the =
geometry since it is stored in the GRASS format, so</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">why should it keep this =
column. What is it you want to do exactly: import</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">a postgis map into GRASS, or =
view a postgis map with GRASS ? See</FONT></P> <P style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: =
12.0px Helvetica">v.external it it is the latter.</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; =
min-height: 14.0px"><BR></P> <P style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">As for indexing, this obviously first of all depends on the =
database</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">backend =
that you use for GRASS maps (e.g. the dbf backend wouldn't =
support</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px =
Helvetica">indexing). You seem to use postgresql as backend, so indexing =
would be</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">possible. =
However, most of the indexes are on the geometry column, so =
they</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT =
face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">would not =
be needed for a map in GRASS format. Why do you want these</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">indexes ?</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; =
min-height: 14.0px"><BR></P> <P style=3D"margin: 0.0px 0.0px 0.0px =
0.0px; font: 12.0px Helvetica; min-height: 14.0px"><BR></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">Moritz</FONT></P> =
</BLOCKQUOTE></DIV><BR><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Thanks for the reply =
Moritz. This all started out as a "can I speed this querry up" exercise. =
Perhaps the=A0fundamental=A0issue is my not completely understanding how =
GRASS makes use of the postgis extension to postgresql. You are correct =
in that I am using psotgresql for database management. I have an =
attribute table of little over a million lines of data in a postgres =
table that is associated with a grass vector. The table contains point =
data based on simple xy utm coordinates.=A0</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>This allows me to run a =
query like:=A0</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>d.vect vector_name size=3D2 =
color=3Dblue where=3D"species=3D'WP' AND diam>40"=A0</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>I would guess that it takes =
d.vect about a minute to draw the results of this query. I have never =
been able to quite figure out how GRASS works with the postgis =
extension. All I was trying to do was speed things up a bit, so I added =
the postgis geometry and spatial indexing to the posgresql table. When I =
discovered that GRASS then didn't behave as I expected (g.copy, =
g.rename), I thought that there were three possible explanations: 1. a =
bug, 2. I didn't have postgis configured properly, 3. (most likely) user =
error, or user not understanding how something was=A0supposed to =
work.</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV>Any =
enlightenment in that last area is much appreciated.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Kirk</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV></BODY></HTML>=
--Apple-Mail-7-148141265--
|
|
Thu, Feb 9 2006
21:50:18
|
|
Mail sent by mlennert@club.worldonline.be
|
|
Return-Path |
<mlennert@club.worldonline.be>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Message-ID |
<39599.85.10.65.247.1139518220.squirrel@geog-pc40.ulb.ac.be>
|
In-Reply-To |
<F73DD52F-15EE-4A32-859F-AB7904FEAF1B@umn.edu>
|
References |
<20060209191113.B81431005A4@lists.intevation.de> <38537.85.10.65.247.1139515147.squirrel@geog-pc40.ulb.ac.be> <F73DD52F-15EE-4A32-859F-AB7904FEAF1B@umn.edu>
|
Date |
Thu, 9 Feb 2006 21:50:20 +0100 (CET)
|
Subject |
Re: [GRASS5] [bug #4075] (grass) grass and postgis issue
|
From |
"Moritz Lennert" <mlennert@club.worldonline.be>
|
To |
"Kirk R. Wythers" <kwythers@umn.edu>
|
Cc |
"Request Tracker" <grass-bugs@intevation.de>, grass5@grass.itc.it
|
User-Agent |
SquirrelMail/1.4.5
|
MIME-Version |
1.0
|
Content-Type |
text/plain;charset=iso-8859-1
|
Content-Transfer-Encoding |
8bit
|
X-Priority |
3 (Normal)
|
Importance |
Normal
|
X-Spam-Status |
No, hits=-3.7 tagged_above=-999.0 required=3.0 tests=BAYES_00, PRIORITY_NO_NAME
|
X-Spam-Level |
|
Hi Kirk,
On Thu, February 9, 2006 21:23, Kirk R. Wythers wrote:
>
> On Feb 9, 2006, at 1:59 PM, Moritz Lennert wrote:
>
>> GRASS doesn't need the geometry since it is stored in the GRASS
>> format, so
>> why should it keep this column. What is it you want to do exactly:
>> import
>> a postgis map into GRASS, or view a postgis map with GRASS ? See
>> v.external it it is the latter.
>>
>> As for indexing, this obviously first of all depends on the database
>> backend that you use for GRASS maps (e.g. the dbf backend wouldn't
>> support
>> indexing). You seem to use postgresql as backend, so indexing would be
>> possible. However, most of the indexes are on the geometry column,
>> so they
>> would not be needed for a map in GRASS format. Why do you want these
>> indexes ?
>>
>>
>> Moritz
>
>
> Thanks for the reply Moritz. This all started out as a "can I speed
> this querry up" exercise. Perhaps the fundamental issue is my not
> completely understanding how GRASS makes use of the postgis extension
> to postgresql. You are correct in that I am using psotgresql for
> database management. I have an attribute table of little over a
> million lines of data in a postgres table that is associated with a
> grass vector. The table contains point data based on simple xy utm
> coordinates.
>
> This allows me to run a query like:
>
> d.vect vector_name size=2 color=blue where="species='WP' AND diam>40"
>
> I would guess that it takes d.vect about a minute to draw the results
> of this query. I have never been able to quite figure out how GRASS
> works with the postgis extension. All I was trying to do was speed
> things up a bit, so I added the postgis geometry and spatial indexing
> to the posgresql table. When I discovered that GRASS then didn't
> behave as I expected (g.copy, g.rename), I thought that there were
> three possible explanations: 1. a bug, 2. I didn't have postgis
> configured properly, 3. (most likely) user error, or user not
> understanding how something was supposed to work.
>
> Any enlightenment in that last area is much appreciated.
>
I will probably be stating the obvious here , but just for the archives:
Your vector data can be stored in different formats: internal GRASS
format, postgis, shape file, etc. GRASS can use these formats in two
different ways: either you import a non-GRASS format file into GRASS
format (v.in.ogr) or you can view it with v.external, which doesn't import
the file, but makes it usable for grass commands.
So, if you import into GRASS vector format, the geometry is stored in the
GRASS format, even if the data is in a postgres table (geometry and data
are handled separately in GRASS. This means that it is no longer a postgis
vector layer, but a GRASS vector layer. Postgis columns in the table or
spatial indices will have no impact as the geometry is not in postgres.
So, adding the geometry column and indices to your postgres data table
will not speed up the process of displaying the map, as d.vect only calls
upon the geometry which is stored in the internal GRASS vector format.
In your case, it would be interesting to see whether the delay of drawing
the results of your d.vect command is due to the geometry, or to the where
clause which doesn't touch upon geometry. The first thing I would try is
to create indices (with the command CREATE INDEX in psql) within your
postgres data table on the columns you query for, i.e. species and diam
(and possibly the combination of both if you will often query for the two
together).
If this doesn't help, then it might be d.vect which is "slow" (a million
points is a large amount of data...) and in order to speed things up it
would be necessary to check whether there is any way to optimise d.vect.
But this is far out of my field of competence.
Hope this helps,
Moritz
|
|
Fri, Feb 10 2006
15:38:37
|
|
Mail sent by kwythers@umn.edu
|
|
Return-Path |
<kwythers@umn.edu>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
X-Umn-Remote-Mta |
[N] truffula.fr.umn.edu [128.101.74.69] #+LO+TS+AU+HN
|
In-Reply-To |
<39599.85.10.65.247.1139518220.squirrel@geog-pc40.ulb.ac.be>
|
References |
<20060209191113.B81431005A4@lists.intevation.de> <38537.85.10.65.247.1139515147.squirrel@geog-pc40.ulb.ac.be> <F73DD52F-15EE-4A32-859F-AB7904FEAF1B@umn.edu> <39599.85.10.65.247.1139518220.squirrel@geog-pc40.ulb.ac.be>
|
Mime-Version |
1.0 (Apple Message framework v746.2)
|
X-Priority |
3 (Normal)
|
Content-Type |
multipart/alternative; boundary=Apple-Mail-1-213838267
|
Message-Id |
<C02A247C-CE99-42F7-8FE2-A48BDB40AE9B@umn.edu>
|
Cc |
"Request Tracker" <grass-bugs@intevation.de>, grass5@grass.itc.it
|
From |
"Kirk R. Wythers" <kwythers@umn.edu>
|
Subject |
Re: [GRASS5] [bug #4075] (grass) grass and postgis issue
|
Date |
Fri, 10 Feb 2006 08:38:31 -0600
|
To |
Moritz Lennert <mlennert@club.worldonline.be>
|
X-Mailer |
Apple Mail (2.746.2)
|
X-Spam-Status |
No, hits=-4.8 tagged_above=-999.0 required=3.0 tests=BAYES_00, HTML_MESSAGE
|
X-Spam-Level |
|
--Apple-Mail-1-213838267
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed
Hi Moritz,
On Feb 9, 2006, at 2:50 PM, Moritz Lennert wrote:
> So, if you import into GRASS vector format, the geometry is stored
> in the
> GRASS format, even if the data is in a postgres table (geometry and
> data
> are handled separately in GRASS. This means that it is no longer a
> postgis
> vector layer, but a GRASS vector layer. Postgis columns in the
> table or
> spatial indices will have no impact as the geometry is not in
> postgres.
This may be a silly question... but what then, is the point of
building GRASS with postgis support? If postgis is really only an
extension that adds geometry column and spatial indexing options to
postgresql, and GRASS does not use the posgis geometry, then why
bother with postgis?
Perhaps the answer to my question is that I do see a speed up with
spatial queries run from GRASS through db.execute (or when I run them
on the database with postgreql). You were right btw Moritz, the slow
response to the command d.vect seems to be at due to the time it
takes d.vect to 'draw'. The same query run in postgis is quite fast.
Also, if I make the query more selective so that fewer data points
get returned. d.vect returns faster (I think because there is less to
draw). Does that make sense to you?
Kirk
--Apple-Mail-1-213838267
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=ISO-8859-1
<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">Hi Moritz,<DIV><BR><DIV><DIV>On =
Feb 9, 2006, at 2:50 PM, Moritz Lennert wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">So, if you import into GRASS =
vector format, the geometry is stored in the</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">GRASS format, even if the =
data is in a postgres table (geometry and data</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">are handled separately in =
GRASS. This means that it is no longer a postgis</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">vector layer, but a GRASS =
vector layer. Postgis columns in the table or</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Helvetica" =
size=3D"3" style=3D"font: 12.0px Helvetica">spatial indices will have no =
impact as the geometry is not in postgres.</FONT></P> =
</BLOCKQUOTE></DIV><BR></DIV><DIV>This may be a silly question... but =
what then, is the point of building GRASS with postgis support? If =
postgis is really only an extension that adds geometry column and =
spatial indexing options to postgresql, and GRASS does not use the =
posgis geometry, then why bother with postgis?=A0</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Perhaps the answer to my =
question is that I do see a speed up with spatial queries run from GRASS =
through db.execute (or when I run them on the database with postgreql). =
You were right btw Moritz, the slow response to the command d.vect seems =
to be at due to the time it takes d.vect to 'draw'. The same query run =
in postgis is quite fast. Also, if I make the query more selective so =
that fewer data points get returned. d.vect returns faster (I think =
because there is less to draw). Does that make sense to =
you?</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Kirk</DIV></BODY></HTML>=
--Apple-Mail-1-213838267--
|
|
Fri, Feb 10 2006
19:42:21
|
|
Mail sent by msieczka
|
|
Kirk
According to Moritz suggestion to close this bug - shall I do it?
Maciek
werchowyna@epf.pl
|
|
Fri, Feb 10 2006
20:05:23
|
|
Mail sent by kwythers@umn.edu
|
|
Return-Path |
<kwythers@umn.edu>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
X-Umn-Remote-Mta |
[N] truffula.fr.umn.edu [128.101.74.69] #+LO+TS+AU+HN
|
Mime-Version |
1.0 (Apple Message framework v746.2)
|
In-Reply-To |
<20060210184221.43E7C100161@lists.intevation.de>
|
References |
<20060210184221.43E7C100161@lists.intevation.de>
|
Content-Type |
text/plain; charset=US-ASCII; delsp=yes; format=flowed
|
Message-Id |
<BBBE55C4-A6DD-45BE-BFFE-8C1B13B3003E@umn.edu>
|
Content-Transfer-Encoding |
7bit
|
From |
"Kirk R. Wythers" <kwythers@umn.edu>
|
Subject |
Re: [bug #4075] (grass) grass and postgis issue
|
Date |
Fri, 10 Feb 2006 13:02:31 -0600
|
To |
Maciek Sieczka via RT <grass-bugs@intevation.de>
|
X-Mailer |
Apple Mail (2.746.2)
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
Yes. It does not seem to be a bug in anything but my own brain.
On Feb 10, 2006, at 12:42 PM, Maciek Sieczka via RT wrote:
> Kirk
>
> According to Moritz suggestion to close this bug - shall I do it?
>
> Maciek
> werchowyna@epf.pl
>
>
> -------------------------------------------- Managed by Request
> Tracker
|
|
Thu, Feb 16 2006
14:26:56
|
|
Status changed to resolved by msieczka
|
|
Thu, Feb 16 2006
14:26:56
|
|
Mail sent by msieczka
|
|
> Yes. It does not seem to be a bug in anything but my own brain.
Cheers :)
Maciek |
|