Hello everyone,
Two questions related to GRASS and PostGIS databases.
First. When I use v.out.ogr to export a vector map to a remote PostGIS
database, the result remote table lacks of a "primary key" constrain,
which causes no problems with some GIS tools (uDIG) and a fatal error
in others (OrbisCAD). Is there any trick to force a primary key field
in the new remote table while exporting?
Second. Can someone describe the goal of pg.postgisdb command in a few
lines? I can see it creates a plpgsql language and a
plpgsql_call_handler() function in a (yet PostGIS-aware?) database
linked to plpgsql.so system library. Doesn't it duplicate the PostGIS
installation process step "createlang plpgsql yourdatabase && psql -f
lwpostgis.sql -d your_database"? And doesn't it mix badly local tools
(my grass local install) and remote services (my remote postgresql +
postgis install)? (execution checks for a postgis install available
locally to pg.postgisdb command, but postgis should be only installed
in remote server where postgresql is).
Thanks in advance,
M.
--
-- marcos boullón magán
On Wed, Mar 22, 2006 at 09:15:55PM +0100, marcos boullón magán wrote:
Hello everyone,
Two questions related to GRASS and PostGIS databases.
First. When I use v.out.ogr to export a vector map to a remote PostGIS
database, the result remote table lacks of a "primary key" constrain,
which causes no problems with some GIS tools (uDIG) and a fatal error
in others (OrbisCAD). Is there any trick to force a primary key field
in the new remote table while exporting?
I feel that a "primary key" support should be added but I
am no expert for v.out.ogr.
Second. Can someone describe the goal of pg.postgisdb command in a few
lines? I can see it creates a plpgsql language and a
plpgsql_call_handler() function in a (yet PostGIS-aware?) database
linked to plpgsql.so system library. Doesn't it duplicate the PostGIS
installation process step "createlang plpgsql yourdatabase && psql -f
lwpostgis.sql -d your_database"? And doesn't it mix badly local tools
(my grass local install) and remote services (my remote postgresql +
postgis install)? (execution checks for a postgis install available
locally to pg.postgisdb command, but postgis should be only installed
in remote server where postgresql is).
I vote for removing pg.postgisdb. It's just an outdated thing, sort
of leftover from GRASS 5.1 times.
Markus
Last question about this, I promise. In GRASS 6.1 cvs,
grass6/db/base/Makefile has commented out the creation of db.createdb,
db.dropdb and db.databases commands (maybe because they are function
calls to unimplemented code in grass/lib/db/stubs/). But GRASS roadmap
for 6.x series shows "DBMS support (done)".
Does it mean that there will be no support to create new databases
from GRASS (not only new tables as now)? And if functionality is in
progress but not finished, will it have PostGIS (out-of-the-box)
support?
Thanks a lot (for spending your time with the newbies),
M.
(BTW. FYI. Sometimes I get confused expressing myself in english. When
in doubt, I was quering for the most obvious piece of info. This means
that yesterday I wasn't saying "I consider that pg.postgisdb is
redundant; please remove it!" but "I don't understand what
pg.postgisdb does". It wasn't a critizism to any command, I remark.)
2006/3/22, Markus Neteler <neteler@itc.it>:
> Second. Can someone describe the goal of pg.postgisdb command in a few
> lines? I can see it creates a plpgsql language and a
> plpgsql_call_handler() function in a (yet PostGIS-aware?) database
> linked to plpgsql.so system library. Doesn't it duplicate the PostGIS
> installation process step "createlang plpgsql yourdatabase && psql -f
> lwpostgis.sql -d your_database"? And doesn't it mix badly local tools
> (my grass local install) and remote services (my remote postgresql +
> postgis install)? (execution checks for a postgis install available
> locally to pg.postgisdb command, but postgis should be only installed
> in remote server where postgresql is).
I vote for removing pg.postgisdb. It's just an outdated thing, sort
of leftover from GRASS 5.1 times.
Markus
--
-- marcos boullón magán
marcos boullón magán wrote:
Last question about this, I promise.
Questions are welcome if not FAQ 
In GRASS 6.1 cvs,
grass6/db/base/Makefile has commented out the creation of db.createdb,
db.dropdb and db.databases commands (maybe because they are function
calls to unimplemented code in grass/lib/db/stubs/). But GRASS roadmap
for 6.x series shows "DBMS support (done)".
Does it mean that there will be no support to create new databases
from GRASS (not only new tables as now)?
Good question.
Since it was there for some time there was a reason to comment it. To me
it would be sort of
intuitive to *have* these commands.
Looking at the ChangeLog:
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/db/base/Makefile
- "drop table removed because it is not implemented in drivers" (radim)
- "removed db.databases, db.createdb, db.dropdb" (radim)
No further explanation. Maybe Radim can tell us more.
And if functionality is in
progress but not finished, will it have PostGIS (out-of-the-box)
support?
Please define out-of-the-box support first - in which sense?
Eg. v.in.db manual page shows an example, since yesterday also the
v.db.connect page and
maybe others.
(BTW. FYI. Sometimes I get confused expressing myself in english. When
in doubt, I was quering for the most obvious piece of info. This means
that yesterday I wasn't saying "I consider that pg.postgisdb is
redundant; please remove it!" but "I don't understand what
pg.postgisdb does". It wasn't a critizism to any command, I remark.)
Constructive critizism is welcome. I have remove the pg.postgisdb script
as it was outdated.
Markus
2006/3/24, Markus Neteler <neteler@itc.it>:
marcos boullón magán wrote:
>Does it mean that there will be no support to create new databases
>from GRASS (not only new tables as now)?
> [...]
>And if functionality is in
>progress but not finished, will it have PostGIS (out-of-the-box)
>support?
>
>
Please define out-of-the-box support first - in which sense?
Eg. v.in.db manual page shows an example, since yesterday also the
v.db.connect page and
maybe others.
After creating a new PostgreSQL database in the server machine, I must
explicitly enable the PostGIS extensions by using a few commands:
(postgresql database creation)
$ createdb mygeodb
(enable plpgsql language processing in db)
$ createlang plpgsql mygeodb
(import spatial processing functions in plpgsql language, and
reference system descriptions)
$ psql -d mygeodb -f lwpostgis.sql
$ psql -d mygeodb -f spatial_ref_sys.sql
And I was wondering wheter database creation from GRASS issued
automatically these instructions to enable PostGIS extensions in a
transparent way for the user. I refered to this as "out-of-the-box
support for postgis" (create new db and use it), maybe confussing
because GRASS has yet a good support to read/write tables in
(existing) PostGIS databases.
But such database setup are simply SQL statements and can be invoked
(easily?) on the new PostgreSQL database in a later step. My fault!
I've just realized this. Then my question is a nonsense, please forget
it, and I'm only replying for the record.
Regards,
M.
-- marcos boullón magán