On Sat, 15 Aug 2020, Micha Silver wrote:
But again, don't confuse - this is NOT PostGIS, and GRASS does not need/use PostGIS for geometry. GRASS geometry is always independent of any external geospatial format.
Micha, Thanks for clarifying; I must have mis-understood what I read. I assumed the geometry was kept by GRASS and didn't know why PostGIS was mentioned ... and I don't recall just where I read all this.
It's the other way around: When you export GRASS map layers, you can, as you know, choose to save out to several formats: shp, Geopackage (the current default) or to PostGIS. PostGIS is the best choice when you need multiuser access to the geospatial data. But you point out that you're the only user, so why would you need the overhead of PostGIS?
Ah, so. I don't.
To repeat, you can set the default for saving attribute tables to PostgreSQL, but do not try to save a GRASS layer to PostGIS in the same database! That will definitely lead to trouble. If you want/need a PostGIS instance for some reason independent of GRASS, then keep it totally separated from GRASS. i.e. at least in a separate schema or even separate database.
No, I want the attribute data in postgres so I need to learn to make that the default.
The main reasons for choosing PostgreSQL as your database backend would be 1. to allow fancy SQL queries on the database tables 2. huge, complex data tables or triggers 3. multiuser access to the attribute tables
My reason is keeping these data in the same format as other project data.
But keep in mind that the default sqlite database is quite powerful, and you would have to look very deeply to find a PostgreSQL feature that is missing in sqlite.
Yes, I've been using SQlite as long as I have PostgreSQL. Thanks, Rich _______________________________________________ grass-user mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/grass-user
