I've read the docs for DBMS use with vector themes/layers and am left with
more questions than answers.
Because my projects will involve only me I'll use SQLite.
1) My initial impression is that I need a separate database for each layer
(i.e., one for highways, a separate one for streams & rivers, etc.). Is this
correct?
2) Do I manually create the databases and specify table schema within each
location's dbf/ directory?
3) If I want to write SELECT statments that JOIN tables in different
layers, then I need to open one database and attach the others. Is this done
within GRASS?
I'm sure that I'll have more questions as I learn how to use SQLite with
vector attributes. The soils data in particular, has a couple of dozen
tables associated with it.
TIA,
Rich
I have very nice results with sqlite+GRASS.
First, use an sqlite administrator software to make things easier.
- My initial impression is that I need a separate database for each layer
(i.e., one for highways, a separate one for streams & rivers, etc.). Is this
correct?
One database for each LOCATION, one table for each vector.
One way of working is that You can put rivers, highways, power lines, etc. in the same “layer” and put a column in the table that describe what kind of object it is. You can play with CAT number too, like rivers is cat number x and highways is cat number y.
Then for example:
Displaying the vector you say: x=blue y=black.
In the sql you say: SELECT * FROM table WHERE description=“river”
Try no to think as the obsolete shapefile style gis.
- Do I manually create the databases and specify table schema within each
location’s dbf/ directory?
Just create the table and connect the LOCATION to it. “db.connect”.
Any new vector or command tha creates a vector, creates also a new table in the sql database.
- If I want to write SELECT statments that JOIN tables in different
layers, then I need to open one database and attach the others. Is this done
within GRASS?
I have never tried joining tables in different databases.
I’m sure that I’ll have more questions as I learn how to use SQLite with
vector attributes. The soils data in particular, has a couple of dozen
tables associated with it.
I am a agronomist engineer an I have made soil maps and soil use maps with grass, just ask if you have more questions.
Pablo Torres Carreira
Brazil.
A vida na frente do computador ficou mais simples: Chegou Windows 7! Clique e Conheça
On Wed, 18 Nov 2009, Pablo Carreira wrote:
I have very nice results with sqlite+GRASS.
Pablo,
I've been using SQLite for several years; it's the back end to my
approximate reasoning model for environmental impact assessments.
First, use an sqlite administrator software to make things easier.
I'm a CLI guy and prefer working by typing.
One database for each LOCATION, one table for each vector.
That's what I thought. Thanks for confirming.
One way of working is that You can put rivers, highways, power lines, etc.
in the same "layer" and put a column in the table that describe what kind
of object it is. You can play with CAT number too, like rivers is cat
number x and highways is cat number y.
I'll need to think about this. Right now I have three locations, based on
regional extent. Most layers are for the entire state, the DEM is for the
northwest portion of the state and the soils are for a single county.
Try no to think as the obsolete shapefile style gis.
I've never used ARC/View. I did use ARC/Info on the Prime in the late
1980s, and a bit of ARC/Info-PC in the same period. Most of the mapping I
did in the 1990s was with MapInfo running under VMware on a linux host. I
last upgraded that in 1996. 
Haven't done any GIS work for about 6 years.
I am a agronomist engineer an I have made soil maps and soil use maps with
grass, just ask if you have more questions.
And I'm a stream ecologist/fluvial geomorphologist so I'm sure I'll have
questions about antecedent soild moisture for the model I'm working toward
building.
Thanks,
Rich
Very interesting Rich, I have looked at you site.
Nice to meet you.
Pablo.
I’ve been using SQLite for several years; it’s the back end to my
approximate reasoning model for environmental impact assessments.
And I’m a stream ecologist/fluvial geomorphologist so I’m sure I’ll have
questions about antecedent soild moisture for the model I’m working toward
building.
Thanks,
Rich
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Chegou o Windows 7: Incrivelmente simples! Clique e conheça.
On Wednesday 18 November 2009, Rich Shepard wrote:
On Wed, 18 Nov 2009, Pablo Carreira wrote:
> I have very nice results with sqlite+GRASS.
Pablo,
I've been using SQLite for several years; it's the back end to my
approximate reasoning model for environmental impact assessments.
> First, use an sqlite administrator software to make things easier.
I'm a CLI guy and prefer working by typing.
> One database for each LOCATION, one table for each vector.
That's what I thought. Thanks for confirming.
I like this setup as well. However I have noticed one major shortcoming of
this approach: when a long-running vector operation is using the SQLite
database, no other processes can access vector attributes. I noticed this
when performing a large v.patch job. No other vector modules that opened the
attribute table would work, or would break with errors. Maybe there is
something that can be done to solve this, however, it seems like the
single-user nature of SQLite is to blame. One SQLite database per vector
seems like a heavy-handed solution, but it would solve some of the
problems--- while creating others...
Cheers,
Dylan
> One way of working is that You can put rivers, highways, power lines,
> etc. in the same "layer" and put a column in the table that describe what
> kind of object it is. You can play with CAT number too, like rivers is
> cat number x and highways is cat number y.
I'll need to think about this. Right now I have three locations, based
on regional extent. Most layers are for the entire state, the DEM is for
the northwest portion of the state and the soils are for a single county.
> Try no to think as the obsolete shapefile style gis.
I've never used ARC/View. I did use ARC/Info on the Prime in the late
1980s, and a bit of ARC/Info-PC in the same period. Most of the mapping I
did in the 1990s was with MapInfo running under VMware on a linux host. I
last upgraded that in 1996. Haven't done any GIS work for about 6
years.
> I am a agronomist engineer an I have made soil maps and soil use maps
> with grass, just ask if you have more questions.
And I'm a stream ecologist/fluvial geomorphologist so I'm sure I'll have
questions about antecedent soild moisture for the model I'm working toward
building.
Thanks,
Rich
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
On Fri, 20 Nov 2009, Dylan Beaudette wrote:
I like this setup as well. However I have noticed one major shortcoming of
this approach: when a long-running vector operation is using the SQLite
database, no other processes can access vector attributes. I noticed this
when performing a large v.patch job. No other vector modules that opened
the attribute table would work, or would break with errors. Maybe there is
something that can be done to solve this, however, it seems like the
single-user nature of SQLite is to blame. One SQLite database per vector
seems like a heavy-handed solution, but it would solve some of the
problems--- while creating others...
Dylan,
Yes, SQLite does not play nicely trying to handle threads for multiple
users. Postgres is much better for that. However, from what you write this
issue is a concern only infrequently, and those can be done unattended using
'at'.
Rich