Still no luck solving SQLite db locking issue. I’ve opted for PG db instead - a nicer solution insofar PG is where the data comes from and goes to in my analytics pipeline. There’s also an efficiency dividend, thanks to the v.out.postgis -t flag - which exports the grass geometries and cat values, but not the attribute table - which is much faster than v.out.ogr, as the grass attribute data is already in PG. I then use psql to do a join in PostGIS on the geom and attribute cat values to build the final table for subsequent analysis in PostGIS. :-))
v.out.postgis -t is a great feature - thanks Martin Landa!!! ---------------------------------------------------------------------- Message: 1 Date: Mon, 19 Jan 2015 00:53:58 +1030 From: Mark Wynter <m...@dimensionaledge.com> To: grass <grass-user@lists.osgeo.org> Subject: [GRASS-user] SQLITE db locking problem Message-ID: <6bd86e4f-3b17-42d1-acc3-25e3a3c29...@dimensionaledge.com> Content-Type: text/plain; charset="windows-1252" Hi everyone I?m having issues with SQLITE as the db driver - I encounter this BUSY warning. Only occurs when patching a particular map, in this case ?temp_nbt_cleaned" which is the largest of the datasets being patched. If I work with smaller datasets, it works fine. Pre-patching, SQLITE DB size is only 170MB. I?ve come across various threads reporting something similar with db locking. But couldn?t find a resolution. I?m running grass70 on Centos65, hosted on AWS.. SQLite is version 3.6.23.1 This is the error message. GRASS 7.0.0svn (nodeclean):/var/tmp > v.patch -e input=temp_t_cleaned,temp_b_cleaned,temp_nbt_cleaned out=temp_patched Patching vector map <temp_t_cleaned>... Patching vector map <temp_b_cleaned>... Patching vector map <temp_nbt_cleaned>... WARNING: Busy SQLITE db, already waiting for 10 seconds? WARNING: Busy SQLITE db, already waiting for 20 seconds? etc etc I encounter no problems patching the maps, including ?temp_nbt_cleaned" if I use PG db driver, or DBF driver. I?m more than comfortable using PG in the backend, but I find v.out.postgis too slow when exporting the resultant dataset back to postgis (possibly because its simultaneously trying to read and write to the same db). I haven?t tested whether v.out.ogr quicker than v.out.postgis. _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
