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

Moritz Lennert mlennert at club.worldonline.be
Thu Feb 9 14:59:07 EST 2006


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 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>





More information about the grass-dev mailing list