On Wednesday 05 November 2008, Corrado wrote:
Dear Dylan,
did you find a solution for your problem? I am going to do the same and I
would not mind seeing your script .... I am going to use postgresql, but I
think I can adapt it.
Thanks in advance.
Hi,
A little late, but here is my approach to converting from DBF --> Sqlite:
# define junk label
junk="_00000"
# reset database connection for this mapset
db.connect driver=sqlite database='$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite.db'
# copy vectors, this will re-make their tables in sqlite file
for x in `g.mlist vect`; do g.copy vect=$x,${x}${junk} ; done
# remove originals
for x in `g.mlist type=vect exclude="*${junk}"` ; do g.remove vect=$x ; done
# remove junk from new names, matching the original names
for x in `g.mlist type=vect` ; do new=`echo $x | sed s/${junk}//g` ; g.rename
vect=${x},${new} ; done
These pages where also helpful:
http://grass.osgeo.org/grass65/manuals/html65_user/grass-sqlite.html
http://grass.osgeo.org/grass65/manuals/html65_user/sql.html
Cheers,
Dylan
On Saturday 25 October 2008 02:01:53 Dylan Beaudette wrote:
> On Tuesday 21 October 2008, Markus Neteler wrote:
> > On Tue, Oct 21, 2008 at 6:01 PM, Dylan Beaudette
> >
> > <dylan.beaudette@gmail.com> wrote:
> > > Hi,
> > >
> > > Is there an elegant solution to migrating an entire location/mapset
> > > to a new DB backend? I am thinking about moving all of the tables
> > > stored in DBF to sqlite, however there are a lot of vectors-- and I
> > > was hoping to avoid changing the connection and copying each one
> > > manually.
> > >
> > > Ideas?
> >
> > Maybe I am missing something but isn't it as easy as
> > - create new mapset
> > - set SQLite or whatever with db.connect
> > - run a "for" loop on g.mlist output, therein g.copy
> > ?
> >
> > Ah, I see: we want this recursively for all mapsets in the location...
> > Another option is to do it within the actual mapset, renaming first
> > all maps to a temporary name, then db.connect, then g.copy
> > locally to the previous name and removal of the temporary maps.
>
> Right- that seems like the best solution for now.
>
> > Since GRASS can be easily batch'ed, this could be done
> > also for the entire location. Maybe Python would be more robust
> > and portable at this point (yes, wanted for GRASS 7 to change
> > to the new SQLite backend).
> >
> > Markus
>
> I'll post a simple script, and then we can work towards making a more
> robust version for conversions.
>
> Cheers,
>
> Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341