I changed the database names so they represent the project rather than the
state in which they're located. The postgres ALTER DATABASE command does the
job quite well. Unfortunately, grass seems to be confused by the name change
and any attempt to access map attributes or overlay (intersect) the table
causes the wxPython GUI to crash and a message appears on the console that
grass was unable to open the old database name (error #16007.1) and unable
to describe the table _LAB (error #16010.1).
After changing the postgres database name I ran db.connect to associate
the new name with the location and mapset. It appears that this does not
change where grass has the old name tucked away. The VAR file has the new
database name.
I want to better understand how grass interacts with postgres and where
it needs to be modified to reflect the new database names. If this is in
one of the db.* modules I missed seeing it.
I’ve also had trouble with using Postgres tables in GRASS and then changing them. If I deleted the tables in the past, it was always very difficult to be able to delete the corresponding vector maps. My only real positive experience in that regard has been to delete the mapset and start anew, but of course that’s about as far from elegant as you can get. Sorry that I don’t know more about the way GRASS interacts with Postgres and where the connection is stored.
Best,
Daniel
–
B.Sc. Daniel Lee
Geschäftsführung für Forschung und Entwicklung
ISIS - International Solar Information Solutions GbR
Vertreten durch: Daniel Lee, Nepomuk Reinhard und Nils Räder
ISIS wird gefördert durch die Bundesrepublik Deutschland, Zuwendungsgeber: Bundesministerium für Wirtschaft und Technologie aufgrund eines Beschlusses des Deutschen Bundestages, sowie durch die Europäische Union, Zuwendungsgeber: Europäischer Sozialfonds. Zusätzliche Unterstützung erhält ISIS von dem Entrepreneurship Cluster Mittelhessen, der Universität Marburg, dem Laboratory for Climatology and Remote Sensing und dem GIS-Lab Marburg.
I changed the database names so they represent the project rather than the
state in which they’re located. The postgres ALTER DATABASE command does the
job quite well. Unfortunately, grass seems to be confused by the name change
and any attempt to access map attributes or overlay (intersect) the table
causes the wxPython GUI to crash and a message appears on the console that
grass was unable to open the old database name (error #16007.1) and unable
to describe the table _LAB (error #16010.1).
After changing the postgres database name I ran db.connect to associate
the new name with the location and mapset. It appears that this does not
change where grass has the old name tucked away. The VAR file has the new
database name.
I want to better understand how grass interacts with postgres and where
it needs to be modified to reflect the new database names. If this is in
one of the db.* modules I missed seeing it.
I've also had trouble with using Postgres tables in GRASS and then
changing them. If I deleted the tables in the past, it was always very
difficult to be able to delete the corresponding vector maps. My only real
positive experience in that regard has been to delete the mapset and start
anew, but of course that's about as far from elegant as you can get. Sorry
that I don't know more about the way GRASS interacts with Postgres and
where the connection is stored.
Daniel,
I'm sure that the grass-postgres interface could use a lot of tuning, but
the developers are probably focused more on other aspects.
For one project, deleting a couple of locations/mapsets would be a hassle,
but do-able as a last resort. The other project has several dozen maps and
postgres tables and I'd hate to have to recreate them all.
What puzzles me is that db.connect -p shows the new database name, but
when I try to import an .e00 file or re-project the vector map, the GUI
crashes; if I do it on the command line, I still get the errors that caused
the GUI to leave.
Hello,
it seems that You are looking for v.db.connect, as You need to
reconnect existing vector data sets to a different database. (Or, if
You are careful, just edit MAPSET/vector/MYMAP/dbln file.)
As goes for a GUI crash, please, report it in the issue tracker, as
WXGUI shouldn't crash if DB connection information isn't correct.
I've also had trouble with using Postgres tables in GRASS and then
changing them. If I deleted the tables in the past, it was always very
difficult to be able to delete the corresponding vector maps. My only real
positive experience in that regard has been to delete the mapset and start
anew, but of course that's about as far from elegant as you can get. Sorry
that I don't know more about the way GRASS interacts with Postgres and
where the connection is stored.
Daniel,
I'm sure that the grass-postgres interface could use a lot of tuning, but
the developers are probably focused more on other aspects.
For one project, deleting a couple of locations/mapsets would be a hassle,
but do-able as a last resort. The other project has several dozen maps and
postgres tables and I'd hate to have to recreate them all.
What puzzles me is that db.connect -p shows the new database name, but
when I try to import an .e00 file or re-project the vector map, the GUI
crashes; if I do it on the command line, I still get the errors that caused
the GUI to leave.
it seems that You are looking for v.db.connect, as You need to reconnect
existing vector data sets to a different database. (Or, if You are
careful, just edit MAPSET/vector/MYMAP/dbln file.)
Maris,
You may very well be correct. I have been looking at only the db.*
commands, not any v.* commands. It makes sense that one knows there are
multiple modules for manipulating map and attribute data when used before.
But, for those of us attempting new operations a cross-reference to all
relevant modules (in this case attribute database related) would be
extremely helpful.
As goes for a GUI crash, please, report it in the issue tracker, as WXGUI
shouldn't crash if DB connection information isn't correct.
OK. I agree that the UI should be independent of module processing.
As goes for a GUI crash, please, report it in the issue tracker, as WXGUI
shouldn't crash if DB connection information isn't correct.
Osgeo didn't like something about my attempts to create an account so I
could post the problem. As it did not tell me what it didn't like, I gave up
after a couple of attempts.
Context: trying to view the attributes of a vector map that apparently was
re-projected without the attributes following along. Results:
DBMI-Postgres driver error:
select * from fluvial where 1 = 0
ERROR: relation "fluvial" does not exist
LINE 1: select * from fluvial where 1 = 0
^
GRASS_INFO_ERROR(30342,1): Unable to describe table <fluvial>
GRASS_INFO_END(30342,1)
GRASS_INFO_ERROR(30345,1): Unable to describe table <fluvial>
GRASS_INFO_END(30345,1)
DBMI-Postgres driver error:
select * from fluvial where 1 = 0
ERROR: relation "fluvial" does not exist
LINE 1: select * from fluvial where 1 = 0
^
GRASS_INFO_ERROR(30425,1): Unable to describe table <fluvial>
GRASS_INFO_END(30425,1)
GRASS_INFO_ERROR(30428,1): Unable to describe table <fluvial>
GRASS_INFO_END(30428,1)
But, for those of us attempting new operations a cross-reference to all
relevant modules (in this case attribute database related) would be
extremely helpful.
it seems it's there, see the bottom of the manual page:
NAME
db.connect - Prints/sets general DB connection for current mapset and exits.
[...]
SEE ALSO
db.columns, db.drivers, db.login, db.tables, v.db.addtable, v.db.connect,
GRASS SQL interface
it seems it's there, see the bottom of the manual page:
NAME
db.connect - Prints/sets general DB connection for current mapset and exits.
[...]
SEE ALSO
db.columns, db.drivers, db.login, db.tables, v.db.addtable, v.db.connect,
Helmut,
Those are only for modules in the db.* family. What I meant by a cross
reference would include all the v.db.* modules, too. It did not occur to me
to look in the vector modules for ones related to database operations.