[GRASS-user] Linking multidimensional data to a single point

GRASS GRASS user
1

Dear GRASS users,

I have a question regarding attaching data where there may me more than one value per category to a single GIS point. Here are a couple of examples; the first may already be taken care of by the temporal GIS component of GRASS, but the second would not be.

EXAMPLE 1:

(Possible answer = temporal GIS)

I want to present a time series of stream gage data. I would like a data table to have:

time water_discharge_m3_s sediment_discharge_m3_s

And to have an entire time series of values for a given grass vector category (i.e. vector point, in this case).

EXAMPLE 2:

I have a series of data on sediment composition at a river site. For each point, I want to have a 2D data table with multiple values for:

grain_size lithology

Is there any way to include these sorts of multi-dimensional relational data in GRASS? (I say multi-dimensional because I can imagine a standard GRASS table containing links to the full data series, for example.)

Thanks for the help!

Andy Wickert

2

On Sun, 15 Mar 2015, Andy Wickert wrote:

EXAMPLE 1:

I want to present a time series of stream gage data. I would like a data
table to have:

time water_discharge_m3_s sediment_discharge_m3_s

And to have an entire time series of values for a given grass vector
category (i.e. vector point, in this case).

Andy,

   This is a typical database table. Each row needs a unique ID. What I do
for all my environmental databases would be something like this:

CREATE TABLE Discharges (
   site VARCHAR(30),
   sampdate DATE, -- or use TIMESTAMP to have date and time in a single
   samptime TIME, -- field.
   h20disch REAL,
   seddisc REAL,
   PRIMARY KEY (site, sampdate, samptime)
)

   Then assign your points to the site column.

EXAMPLE 2:

I have a series of data on sediment composition at a river site. For each
point, I want to have a 2D data table with multiple values for:

grain_size lithology

   This would have a similar table structure. Columns (attributes) would
include sediment sample ID (the table's primary key that refers to a table
of sediment samples by location, date, and time), grain size, and
lithography.

   From a statistical analytic point of view I would look at each sample as a
composition and apply models suitable for compositional data analysie (CoDA)
to them. CoDA was developed by geochemists and is appropriate for your data.

HTH,

Rich

--
Richard B. Shepard, Ph.D.
Applied Ecosystem Services, Inc. | Troutdale, OR 97060 USA
www.appl-ecosys.com Voice: 503-667-4517 Fax: 503-667-8863

3

On Sun, Mar 15, 2015 at 4:08 PM, Rich Shepard <rshepard@appl-ecosys.com>
wrote:

On Sun, 15 Mar 2015, Andy Wickert wrote:

EXAMPLE 1:

I want to present a time series of stream gage data. I would like a data
table to have:

time water_discharge_m3_s sediment_discharge_m3_s

And to have an entire time series of values for a given grass vector
category (i.e. vector point, in this case).

Andy,

  This is a typical database table. Each row needs a unique ID. What I do
for all my environmental databases would be something like this:

CREATE TABLE Discharges (
  site VARCHAR(30),
  sampdate DATE, -- or use TIMESTAMP to have date and time in a single
  samptime TIME, -- field.
  h20disch REAL,
  seddisc REAL,
  PRIMARY KEY (site, sampdate, samptime)
)

  Then assign your points to the site column.

EXAMPLE 2:

I have a series of data on sediment composition at a river site. For each
point, I want to have a 2D data table with multiple values for:

grain_size lithology

  This would have a similar table structure. Columns (attributes) would
include sediment sample ID (the table's primary key that refers to a table
of sediment samples by location, date, and time), grain size, and
lithography.

  From a statistical analytic point of view I would look at each sample as
a
composition and apply models suitable for compositional data analysie
(CoDA)
to them. CoDA was developed by geochemists and is appropriate for your
data.

HTH,

Rich

--

Richard B. Shepard, Ph.D.
Applied Ecosystem Services, Inc. | Troutdale, OR 97060 USA
www.appl-ecosys.com Voice: 503-667-4517 Fax: 503-667-8863
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Thanks Rich,

So to boil it down to the simplest part of what you said, the key is just
to have an ID column in the GRASS table that links to a table in a database
structure outside of GRASS? Just to make sure that I was clear: the problem
is how to include multiple rows of data that all correspond to just one
point in GIS (so "grain size" with frequencies in each grain size class or
"discharge" with discharges at different times).

Best,

Andy

4

On Sun, 15 Mar 2015, Andy Wickert wrote:

So to boil it down to the simplest part of what you said, the key is just
to have an ID column in the GRASS table that links to a table in a
database structure outside of GRASS?

Andy,

   Yes. You can keep all point attributes in SQLite (or other rdbms) tables
rather than in GRASS. It's been a while since I last did this so the
specifics are not immediately available. I would link each point to a table
which describes it; perhaps including geographic coordinates, name, and
other information. Then your discharge and sediment data are in other tables
that are related to each row in the main table. This also allows you to run
SQL queries on the data (such as descriptice statistics) outside of GRASS.

Just to make sure that I was clear: the problem is how to include multiple
rows of data that all correspond to just one point in GIS (so "grain size"
with frequencies in each grain size class or "discharge" with discharges
at different times).

   Database design is a topic of itself. Separate attribute data from the
spatial data; the former goes into a database (multiple tables), the latter
in GRASS files.

   In your initial message you describe three different categories of data
and each should be in its own table. Information about each data collection
point (which is seen on the map) is in one table. This could include a site
ID as the primary key, site name, perhaps the stream or drainage basin in
which it is located, and other information about the location itself.

   Your second table contains hydaulic data: sample ID (the primary key),
station ID (which relates that row to your point), collection date and time,
discharge, channel width, and any other relevant information.

   Your third table contains sediment data: sample ID (primary key), station
ID, date and time, each grain category (e.g., silt, clay, fine sand, coarse
sand, gravel, cobble), and the percentage or proportion (dry weight?) of
each.

   You could also have additional tables if you want to store more categories
of data for each point.

Hope this helps,

Rich

5

Rich Shepard <rshepard@appl-ecosys.com> schreef op 15 maart 2015 23:49:06 CET:

On Sun, 15 Mar 2015, Andy Wickert wrote:

So to boil it down to the simplest part of what you said, the key is

just

to have an ID column in the GRASS table that links to a table in a
database structure outside of GRASS?

Andy,

Yes. You can keep all point attributes in SQLite (or other rdbms)
tables
rather than in GRASS.

The attribute table is in a sqlite table already, unless you are still using dbf as database backend for grass. Just link your other tables to that attribute table?

It's been a while since I last did this so the

specifics are not immediately available. I would link each point to a
table
which describes it; perhaps including geographic coordinates, name, and
other information. Then your discharge and sediment data are in other
tables
that are related to each row in the main table. This also allows you to
run
SQL queries on the data (such as descriptice statistics) outside of
GRASS.

Just to make sure that I was clear: the problem is how to include

multiple

rows of data that all correspond to just one point in GIS (so "grain

size"

with frequencies in each grain size class or "discharge" with

discharges

at different times).

Database design is a topic of itself. Separate attribute data from the
spatial data; the former goes into a database (multiple tables), the
latter
in GRASS files.

In your initial message you describe three different categories of data
and each should be in its own table. Information about each data
collection
point (which is seen on the map) is in one table. This could include a
site
ID as the primary key, site name, perhaps the stream or drainage basin
in
which it is located, and other information about the location itself.

Your second table contains hydaulic data: sample ID (the primary key),
station ID (which relates that row to your point), collection date and
time,
discharge, channel width, and any other relevant information.

Your third table contains sediment data: sample ID (primary key),
station
ID, date and time, each grain category (e.g., silt, clay, fine sand,
coarse
sand, gravel, cobble), and the percentage or proportion (dry weight?)
of
each.

You could also have additional tables if you want to store more
categories
of data for each point.

Hope this helps,

Rich

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

6

On Sun, Mar 15, 2015 at 11:49 PM, Rich Shepard <rshepard@appl-ecosys.com>
wrote:

On Sun, 15 Mar 2015, Andy Wickert wrote:

So to boil it down to the simplest part of what you said, the key is just

to have an ID column in the GRASS table that links to a table in a
database structure outside of GRASS?

Andy,

  Yes. You can keep all point attributes in SQLite (or other rdbms) tables
rather than in GRASS. It's been a while since I last did this so the
specifics are not immediately available. I would link each point to a table
which describes it; perhaps including geographic coordinates, name, and
other information. Then your discharge and sediment data are in other
tables
that are related to each row in the main table. This also allows you to run
SQL queries on the data (such as descriptice statistics) outside of GRASS.

Just to make sure that I was clear: the problem is how to include multiple

rows of data that all correspond to just one point in GIS (so "grain size"
with frequencies in each grain size class or "discharge" with discharges
at different times).

  Database design is a topic of itself. Separate attribute data from the
spatial data; the former goes into a database (multiple tables), the latter
in GRASS files.

  In your initial message you describe three different categories of data
and each should be in its own table. Information about each data collection
point (which is seen on the map) is in one table. This could include a site
ID as the primary key, site name, perhaps the stream or drainage basin in
which it is located, and other information about the location itself.

  Your second table contains hydaulic data: sample ID (the primary key),
station ID (which relates that row to your point), collection date and
time,
discharge, channel width, and any other relevant information.

  Your third table contains sediment data: sample ID (primary key), station
ID, date and time, each grain category (e.g., silt, clay, fine sand, coarse
sand, gravel, cobble), and the percentage or proportion (dry weight?) of
each.

  You could also have additional tables if you want to store more
categories
of data for each point.

Hope this helps,

Rich

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Hi Rich,

This helps very much and learning how to do this will be high on my to-do
list. Thank you!

Andy

7

On Sun, 15 Mar 2015, Paulo van Breugel wrote:

The attribute table is in a sqlite table already, unless you are still
using dbf as database backend for grass. Just link your other tables to
that attribute table?

Paulo,

   Thanks for reminding us. I forgot about that. You are correct that the
thing to do is link the other tables to that attribute table.

Rich

8

On Mon, Mar 16, 2015 at 9:07 PM, Rich Shepard <rshepard@appl-ecosys.com>
wrote:

On Sun, 15 Mar 2015, Paulo van Breugel wrote:

The attribute table is in a sqlite table already, unless you are still

using dbf as database backend for grass. Just link your other tables to
that attribute table?

Paulo,

  Thanks for reminding us. I forgot about that. You are correct that the
thing to do is link the other tables to that attribute table.

Rich

Thanks Paulo and Rich,

So would this be adding additional SQL database tables as additional
"layers" associated with a GRASS GIS vector data set? I had thought that
the layers also needed to be linked to vector points... so I'm guessing
that this would still be linking outside SQL tables to the GRASS table?

Thinking "out loud" and putting my reasoning in an email in case someone
seeing this conversation is helped by this later.

Andy

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

9

On Mon, 16 Mar 2015, Andy Wickert wrote:

So would this be adding additional SQL database tables as additional
"layers" associated with a GRASS GIS vector data set? I had thought that
the layers also needed to be linked to vector points... so I'm guessing
that this would still be linking outside SQL tables to the GRASS table?

Andy,

   Nope. Additional tables to the same map/layer. You have a map of data
collection locations. Perhaps you have other layers/coverages of roads, land
use/land cover, even a raster of the terrain (based on a DEM). To any of
these layers you can have as many relational database tables as is
appropriate to the chunks of data you have associated with each feature on a
single layer.

   You are adding attribute data to each point on your one map. That's done
behind the scenes in SQLite and is not visible on the map.

   Depending on your use of this application, you might use the discharge or
sediment composition data to procues heat maps of intensities, or do other
kewel stuff with your data, but you'll probably end up analyzing your data
with R and producing spiffy plots to accompany the spatial analyses you run.

Rich