[GRASS-dev] STVDS where only attributes change over time?

[Sören Gebbert]

Dear Stefan,
The GRASS GIS temporal framework supports the time stamping of vector
layers/tables (former called fields). Hence, you can create any number
of layers for a single vector map and assign a different attribute
table to each layer. This leads to the ability to separately time
stamp each layer&table of a vector map.

The temporal module t.vect.oberve.strds uses this feature.

However, since the analysis capabilities of space time vector datasets
are limited in the temporal framework, i would suggest to use a
temporal database for this task.

Best regards
Soeren

Btw:
You can try to use the Grass-Data-Explorer to analyse GRASS GIS time
series data in Qgis inclusively statistical analsys:
https://bitbucket.org/huhabla/grass-data-explorer


2015-12-11 15:49 GMT+01:00 Blumentrath, Stefan <Stefan.Blumentrath at nina.no>:
> Hi devs,
>
>
>
> The TGRASS concept is a great enhancement to GRASS which already proved it`s
> usefulness for my daily work with raster data in many cases. Now I am
> discovering the vector part of it. If I understand correctly, the concept
> for vector data is identically to the raster part, namely using whole, time
> stamped vector datasets.
>
>
>
> In long term monitoring, where time series play a central role, one often
> has a fixed location and only attributes are updated (as it is the case in
> e.g. detailed vegetation studies, temperature logger, wildlife camera
> traps...). In such cases having geometries for each registration of data
> would lead to significant redundancy of data and unnecessary computation
> (building topology, spatially matching each map...).
>
>
>
> My question is now, how much work would it cause to introduce a new type of
> space time dataset with fixed geometries and a linked attribute table which
> contains the temporal information along with (variable) attribute values
> (“Space Time Vector Attribute Datasets”)?
>
>
>
> What would have to be changed?
>
>
>
> Is it more appropriate to stick to database solutions (e.g. PostGIS) or R
> (or a combination of the two) and eventually fetch data from STRDS?
>
>
>
> Kind regards,
>
> Stefan
>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev