Re: sqlite and grass65: was Re: [GRASS-dev] sqlite and grass64
Re. the missing functionality of DBF, would it be feasible for v.db.join to import the DBF table to a temp SQLite file, do the join and export it back to a DBF? Would the same thing be possible for other SQL ops that DBF does not support? For where=SQL module options? It should be possible to ship SQLite with GRASS, shouldn't it -- given it's highly portable and consumes < 250K? Plus can be fully embedded w/o conflicting with system-wide installs? I suppose SpatiaLite would be an ideal exchange format for vector maps. Just some thoughts... Cheers, Ben Moritz Lennert wrote: > On 06/03/09 01:24, Moskovitz, Bob wrote: Concerning the need to be able to easily backup/share, I >>> think we definitely need some module which isolates and exports a series of >>> chosen maps in a new temporary mapset with a local sqlite db file, copies the >>> chosen maps into this temp mapset and then creates a tarball (or zip or >>> whatever) with the basic LOCATION info (i.e. a PERMANENT mapset with PROJ and >>> WIND files) and the temp mapset. Shouldn't be too hard to wip up, or ? >>> Essentially a v.pack/v.unpack, right? >>> >>> Markus >> >> What would be really neat is if there was a way to delete, as well as >> archive a location from the startup screen. > > That should actually be much easier. Deleting just implies removing the > directory from the file system, archiving just needs a call to create a > tar ball or equivalent. So, essentially a small GUI to call one single > command. > > v.pack/v.unpack would be different in that it should deal with > individual maps. even though I suggest to include the location info as > sort of meta-data, but also to give the possibility to v.unpack into a > new, stand-alone location. Don't know if the last is really necessary, > though. Just including necessary meta-data concerning the projection > system should be enough. > > Moritz > >> >> Bob >> > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > > -- Benjamin Ducke Senior Applications Support and Development Officer Oxford Archaeology Janus House Osney Mead OX2 0ES Oxford, U.K. Tel.: ++44 (0)1865 263 800 benjamin.du...@oxfordarch.co.uk -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: sqlite and grass65: was Re: [GRASS-dev] sqlite and grass64
On 06/03/09 01:24, Moskovitz, Bob wrote: Concerning the need to be able to easily backup/share, I think we definitely need some module which isolates and exports a series of chosen maps in a new temporary mapset with a local sqlite db file, copies the chosen maps into this temp mapset and then creates a tarball (or zip or whatever) with the basic LOCATION info (i.e. a PERMANENT mapset with PROJ and WIND files) and the temp mapset. Shouldn't be too hard to wip up, or ? Essentially a v.pack/v.unpack, right? Markus What would be really neat is if there was a way to delete, as well as archive a location from the startup screen. That should actually be much easier. Deleting just implies removing the directory from the file system, archiving just needs a call to create a tar ball or equivalent. So, essentially a small GUI to call one single command. v.pack/v.unpack would be different in that it should deal with individual maps. even though I suggest to include the location info as sort of meta-data, but also to give the possibility to v.unpack into a new, stand-alone location. Don't know if the last is really necessary, though. Just including necessary meta-data concerning the projection system should be enough. Moritz Bob ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: sqlite and grass65: was Re: [GRASS-dev] sqlite and grass64
On 05/03/09 19:04, Markus Neteler wrote: On Thu, Mar 5, 2009 at 4:38 PM, Moritz Lennert wrote: On 05/03/09 10:43, Markus Neteler wrote: .. Suggestion: make SQLite as default DBMS driver in devel_branch6 (alias GRASS 6.5). Since today, in 2009, the driver has received a lot of testing, is definitely superiour to DBF (where we regularly get complaints). +1 If allowing one file per map isn't too hard to implement as optional feature it might be a (last) requirement to make it the default driver. I think that for the same arguments as those brought forward by Glynn above, we should make single file db the default. Anyone who really needs it can easily create a per-vector db with v.db.connect. Remember that Glynn mentioned that joins won't work in this case. Sorry, apparently I wasn't clear: by "single-file db" I meant one db file holding all tables, so allowing joins. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: sqlite and grass65: was Re: [GRASS-dev] sqlite and grass64
Markus Neteler wrote: > If allowing one file per map isn't too hard to implement as optional feature > it might be a (last) requirement to make it the default driver. AFAICT, there are two obvious ways to do this: 1. Have two SQLite drivers, one using a single file, the other using one file per map. These can both be built from the same directory (see the db/drivers/mysql, which builds both the mysql and mesql drivers). 2. If DB_DATABASE refers to an existing directory or ends in a slash, create a file in that directory with the same name as the map. Otherwise treat it as the name of the DB file used for all maps. -- Glynn Clements ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: sqlite and grass65: was Re: [GRASS-dev] sqlite and grass64
On Mar 5, 2009, at 5:44 PM, wrote:
Date: Thu, 5 Mar 2009 16:24:38 -0800
From: "Moskovitz, Bob"
Subject: RE: sqlite and grass65: was Re: [GRASS-dev] sqlite and
grass64
To: "Markus Neteler" , "Moritz Lennert"
Cc: GRASS developers list
Message-ID:
Content-Type: text/plain; charset="iso-8859-1"
Concerning the need to be able to easily backup/share, I
think we definitely
need some module which isolates and exports a series of
chosen maps in a new
temporary mapset with a local sqlite db file, copies the
chosen maps into
this temp mapset and then creates a tarball (or zip or
whatever) with the
basic LOCATION info (i.e. a PERMANENT mapset with PROJ and
WIND files) and
the temp mapset. Shouldn't be too hard to wip up, or ?
Essentially a v.pack/v.unpack, right?
Markus
What would be really neat is if there was a way to delete, as well
as archive a location from the startup screen.
Bob
You can delete or rename a location or a mapset from the wxPython
startup screen.
Michael
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: sqlite and grass65: was Re: [GRASS-dev] sqlite and grass64
On Mar 5, 2009, at 5:44 PM, wrote: Date: Thu, 5 Mar 2009 19:04:46 +0100 From: Markus Neteler Subject: Re: sqlite and grass65: was Re: [GRASS-dev] sqlite and grass64 To: Moritz Lennert Cc: GRASS developers list Message-ID: <86782b610903051004n5601199ax269f60f1949c6...@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 5, 2009 at 4:38 PM, Moritz Lennert wrote: On 05/03/09 10:43, Markus Neteler wrote: .. Suggestion: make SQLite as default DBMS driver in devel_branch6 (alias GRASS 6.5). Since today, in 2009, the driver has received a lot of testing, is definitely superiour to DBF (where we regularly get complaints). +1 If allowing one file per map isn't too hard to implement as optional feature it might be a (last) requirement to make it the default driver. I think that for the same arguments as those brought forward by Glynn above, we should make single file db the default. Anyone who really needs it can easily create a per-vector db with v.db.connect. Remember that Glynn mentioned that joins won't work in this case. Concerning the need to be able to easily backup/share, I think we definitely need some module which isolates and exports a series of chosen maps in a new temporary mapset with a local sqlite db file, copies the chosen maps into this temp mapset and then creates a tarball (or zip or whatever) with the basic LOCATION info (i.e. a PERMANENT mapset with PROJ and WIND files) and the temp mapset. Shouldn't be too hard to wip up, or ? Essentially a v.pack/v.unpack, right? Markus I like the idea of sqlite. But I also favor 1 db per vector. Portability is important. Think about the issues with ArcGIS (a real pain). Joins between different vectors indeed won't work if there is one db per vector. But how many times does one want to join the attribute table of one vector with the attribute table of a different vector? I'm sure that there could be cases, but I'd warrant that there aren't many. More often one wants to join multiple tables for the SAME vector. In this case, you would have multiple tables for a single vector db. Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: sqlite and grass65: was Re: [GRASS-dev] sqlite and grass64
> > Concerning the need to be able to easily backup/share, I > think we definitely > > need some module which isolates and exports a series of > chosen maps in a new > > temporary mapset with a local sqlite db file, copies the > chosen maps into > > this temp mapset and then creates a tarball (or zip or > whatever) with the > > basic LOCATION info (i.e. a PERMANENT mapset with PROJ and > WIND files) and > > the temp mapset. Shouldn't be too hard to wip up, or ? > > Essentially a v.pack/v.unpack, right? > > Markus What would be really neat is if there was a way to delete, as well as archive a location from the startup screen. Bob ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: sqlite and grass65: was Re: [GRASS-dev] sqlite and grass64
On Thu, Mar 5, 2009 at 4:38 PM, Moritz Lennert wrote: > On 05/03/09 10:43, Markus Neteler wrote: .. >> Suggestion: >> make SQLite as default DBMS driver in devel_branch6 (alias GRASS 6.5). >> Since today, in 2009, the driver has received a lot of testing, is >> definitely superiour to DBF (where we regularly get complaints). > > +1 > >> >> If allowing one file per map isn't too hard to implement as optional >> feature it might be a (last) requirement to make it the default driver. > > I think that for the same arguments as those brought forward by Glynn above, > we should make single file db the default. Anyone who really needs it can > easily create a per-vector db with v.db.connect. Remember that Glynn mentioned that joins won't work in this case. > Concerning the need to be able to easily backup/share, I think we definitely > need some module which isolates and exports a series of chosen maps in a new > temporary mapset with a local sqlite db file, copies the chosen maps into > this temp mapset and then creates a tarball (or zip or whatever) with the > basic LOCATION info (i.e. a PERMANENT mapset with PROJ and WIND files) and > the temp mapset. Shouldn't be too hard to wip up, or ? Essentially a v.pack/v.unpack, right? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: sqlite and grass65: was Re: [GRASS-dev] sqlite and grass64
On 05/03/09 10:43, Markus Neteler wrote: Coming back to an old thread: (SQLite as default DBMS driver) On Mon, Jan 14, 2008 at 12:55 AM, Glynn Clements wrote: Hamish wrote: Are there any instances where the dbf driver can do some functionality that the sqlite driver cannot? I use the sqlite driver all the time for my work with no problems. DBF works "out of the box" on all platforms and is as well tested and implimented as these things get. Its problems are well known. AFAIU SQLite (by default) stores the DBs for all vector maps in a single file per mapset. This makes it hard to share individual vector maps and may have LFS issues when your data + mapset gets to be huge. (??) I doubt that LFS will be an issue in practice; I doubt that you'll find an SQLite without LFS on any platform which supports it (i.e. everything except for ancient Unices). It probably wouldn't be hard to modify the SQLite DBMI driver to allow one file per map (like for DBF), but then you lose the ability to perform joins (OTOH, if you're using DBF, you never had this ability in the first place). Personally, I feel that the DBF driver is sufficiently "sub par" compared to any other DBMS that I wouldn't consider "won't work with the DBF driver" to be a valid design consideration in GRASS. Developers should feel free to use e.g. arithmetic operators and joins in SQL queries, rather than being constrained by the rather limited capabilities of the DBF driver. Suggestion: make SQLite as default DBMS driver in devel_branch6 (alias GRASS 6.5). Since today, in 2009, the driver has received a lot of testing, is definitely superiour to DBF (where we regularly get complaints). +1 If allowing one file per map isn't too hard to implement as optional feature it might be a (last) requirement to make it the default driver. I think that for the same arguments as those brought forward by Glynn above, we should make single file db the default. Anyone who really needs it can easily create a per-vector db with v.db.connect. Concerning the need to be able to easily backup/share, I think we definitely need some module which isolates and exports a series of chosen maps in a new temporary mapset with a local sqlite db file, copies the chosen maps into this temp mapset and then creates a tarball (or zip or whatever) with the basic LOCATION info (i.e. a PERMANENT mapset with PROJ and WIND files) and the temp mapset. Shouldn't be too hard to wip up, or ? Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: sqlite and grass65: was Re: [GRASS-dev] sqlite and grass64
On Mar 5, 2009, at 3:43 AM, Markus Neteler wrote: Suggestion: make SQLite as default DBMS driver in devel_branch6 (alias GRASS 6.5). Since today, in 2009, the driver has received a lot of testing, is definitely superiour to DBF (where we regularly get complaints). If allowing one file per map isn't too hard to implement as optional feature it might be a (last) requirement to make it the default driver. If the joining between db files is a problem, a single file is OK with me as the default. But then have the creation of a separate db file a creation option for vectors, then there is still the convenience of being able to isolate a vector for backup or sharing. - William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: sqlite and grass65: was Re: [GRASS-dev] sqlite and grass64
>Suggestion: >make SQLite as default DBMS driver in devel_branch6 (alias GRASS 6.5). >Since today, in 2009, the driver has received a lot of testing, is definitely >superiour to DBF (where we regularly get complaints). > > >Markus +1. I think it's a great idea. ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: sqlite and grass65: was Re: [GRASS-dev] sqlite and grass64
Hi, 2009/3/5 Markus Neteler : [...] > make SQLite as default DBMS driver in devel_branch6 (alias GRASS 6.5). > Since today, in 2009, the driver has received a lot of testing, is definitely > superiour to DBF (where we regularly get complaints). > > If allowing one file per map isn't too hard to implement as optional feature > it might be a (last) requirement to make it the default driver. > > What are the opinions? I would agree even there are a few unsolved issues - e.g. problem with dissolving areas based on character column data type. M. -- Martin Landa * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
