
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">‘’’<div><br style="-webkit-text-size-adjust: auto; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><span style="-webkit-text-size-adjust: auto; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">When importing a shapefile or other vector data, only the attrib tables get saved to some database: sqlite by default, or PostgrSQL if you have configured for that backend. But the geometry is still kept in the GRASS vector format.</span></div><div><font color="#000000"><span style="caret-color: rgb(0, 0, 0); -webkit-text-size-adjust: auto;">‘’’</span></font></div><div><font color="#000000"><span style="caret-color: rgb(0, 0, 0); -webkit-text-size-adjust: auto;"><br></span></font></div><div><font color="#000000"><span style="caret-color: rgb(0, 0, 0); -webkit-text-size-adjust: auto;">1. How would one configure that? Please assume that I am unfamiliar and uncomfortable with GRASS when explaining, but able to read Java and Python man pages with ease, also comfortable with PSQL and PostGIS.</span></font></div><div><font color="#000000"><span style="caret-color: rgb(0, 0, 0); -webkit-text-size-adjust: auto;">2. Would we get all the speed benefits of PSQL, would it be used for computations whenever possible?</span></font></div><div><font color="#000000"><span style="caret-color: rgb(0, 0, 0); -webkit-text-size-adjust: auto;">3. Is there a way to easily move from GRASS and PSQL geometry and topology models when doing this?</span></font></div><div><br><div dir="ltr">Sent from my iPhone</div><div dir="ltr"><br><blockquote type="cite">On Aug 15, 2020, at 7:50 AM, Rich Shepard <rshepard@appl-ecosys.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span>On Sat, 15 Aug 2020, Micha Silver wrote:</span><br><span></span><br><blockquote type="cite"><span>But again, don't confuse - this is NOT PostGIS, and GRASS does not</span><br></blockquote><blockquote type="cite"><span>need/use PostGIS for geometry. GRASS geometry is always independent of any</span><br></blockquote><blockquote type="cite"><span>external geospatial format.</span><br></blockquote><span></span><br><span>Micha,</span><br><span></span><br><span>Thanks for clarifying; I must have mis-understood what I read. I assumed the</span><br><span>geometry was kept by GRASS and didn't know why PostGIS was mentioned ... and</span><br><span>I don't recall just where I read all this.</span><br><span></span><br><blockquote type="cite"><span>It's the other way around: When you export GRASS map layers, you can, as</span><br></blockquote><blockquote type="cite"><span>you know, choose to save out to several formats: shp, Geopackage (the</span><br></blockquote><blockquote type="cite"><span>current default) or to PostGIS. PostGIS is the best choice when you need</span><br></blockquote><blockquote type="cite"><span>multiuser access to the geospatial data. But you point out that you're the</span><br></blockquote><blockquote type="cite"><span>only user, so why would you need the overhead of PostGIS?</span><br></blockquote><span></span><br><span>Ah, so. I don't.</span><br><span></span><br><blockquote type="cite"><span>To repeat, you can set the default for saving attribute tables to</span><br></blockquote><blockquote type="cite"><span>PostgreSQL, but do not try to save a GRASS layer to PostGIS in the same</span><br></blockquote><blockquote type="cite"><span>database! That will definitely lead to trouble. If you want/need a PostGIS</span><br></blockquote><blockquote type="cite"><span>instance for some reason independent of GRASS, then keep it totally</span><br></blockquote><blockquote type="cite"><span>separated from GRASS. i.e. at least in a separate schema or even separate</span><br></blockquote><blockquote type="cite"><span>database.</span><br></blockquote><span></span><br><span>No, I want the attribute data in postgres so I need to learn to make that</span><br><span>the default.</span><br><span></span><br><blockquote type="cite"><span>The main reasons for choosing PostgreSQL as your database backend would be</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>1. to allow fancy SQL queries on the database tables</span><br></blockquote><blockquote type="cite"><span>2. huge, complex data tables or triggers</span><br></blockquote><blockquote type="cite"><span>3. multiuser access to the attribute tables</span><br></blockquote><span></span><br><span>My reason is keeping these data in the same format as other project data.</span><br><span></span><br><blockquote type="cite"><span>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.</span><br></blockquote><span></span><br><span>Yes, I've been using SQlite as long as I have PostgreSQL.</span><br><span></span><br><span>Thanks,</span><br><span></span><br><span>Rich</span><br><span>_______________________________________________</span><br><span>grass-user mailing list</span><br><span>grass-user@lists.osgeo.org</span><br><span>https://lists.osgeo.org/mailman/listinfo/grass-user</span></div></blockquote></div></body></html>