Details Ticket 4075


Comment | Reply | Take | Open


Serial Number 4075
Subject grass and postgis issue
Area grass6
Queue grass
Requestors kwythers@umn.edu
Owner none
Status resolved
Last User Contact Thu Feb 16 14:26:56 2006 (3 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Thu Feb 16 14:26:56 2006 (3 yr ago)
Created Thu Feb 9 20:11:13 2006 (3 yr ago)

Transaction History Ticket 4075


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
Comment | Reply | Take | Open

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request