[GRASS5] [bug #4075] (grass) grass and postgis issue

[Moritz Lennert]

Kirk R. Wythers wrote:
> 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? 

What do you mean by building "with postgis support" ? Postgis is 
supported via ogr. Postgresql support, however, is necessary to be able 
to use postgresql tables as database backend.

I think you shouldn't forget that GRASS is not a cartography program but 
a full GIS with its own geometry format and data handling. So, using 
postgis layers in GRASS doesn't really make sense, unless it is for the 
occasional situation where you need to access.

One disadvantage of the postgis format is that it obliges you to install 
a postgresql server...The standard format in GRASS (with its own 
geometry format plus dbf and possibly sqlite as database backend) does 
not impose the need for a full-fledged database server.

> 
> 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).

What exactly do you mean by spatial queries ? The query you mentioned 
before (i.e. d.vect vector_name size=2 color=blue where="species='WP' 
AND diam>40") is not a "spatial query" in my defintion, but a simple 
query over the data. A spatial query would imply things like "all points 
within a certain distance of X", or "all points within area Y", etc.

> 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'.

Does this mean that you created indices on the variables you query for 
in your postgres data table linked to the GRASS vector layer (such as 
species and diam in the above query) and this doesn't make a difference ?

> The same query run in postgis is quite fast. 

Actually you mean postgresql, since the above query doesn't use any 
postgis features if I am not mistaking.

In addition, you did not display a map, or ?
How does running your query through db.select or v.db.select compare to 
postgresql ? That shouldn't be any different unless the GRASS postgresql 
introduces some slowing effects.

> 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?

Obviously displaying less features will take less time. But it might 
also be that the query runs quicker. Try to compare d.vect with 
v.db.select and see.

BTW, I don't think that this should be considered a bug. So the bug 
report can be closed and we should continue this discussion only on the 
list.

Moritz