[GRASS-user] Aggregating daily maps in relative strds per month

[Nikos Alexandris]

* Sören Gebbert <soerengebbert at googlemail.com> [2015-05-18 23:17:55 +0200]:

> Hi Nikos,
> 
> 2015-05-18 23:07 GMT+02:00 Nikos Alexandris <nik at nikosalexandris.net>:
> > * Sören Gebbert <soerengebbert at googlemail.com> [2015-05-18 20:34:19 +0200]:
> >
> >> Hi Nikos,
> >> You need to use t.remove to delete the time stamps from the temporal
> >> database. The *.timestamp modules should not be used at all. They are not
> >> connected with the temporal framework.
> >> The error appears because the maps still have relative time stamps in the
> >> temporal database which can not be overwritten with absolute time stamps.
> >
> > Thanks for spotting.  I am not sure about the following:
> >
> > 1) how does t.connect/t.create work if I erase the "tgis"
> > directory manually?  Is it not possible to create a new tgis from
> > scratch?
> 
> The tgis directory can be removed, all temporal commands will check if
> the mapset specific temporal database exists and will create one if
> needed.

I removed the tgis directory manually (rm -rf). Then issued `t.connect -d` or/and
`t.connect -c`. Though this sets the connection driver/path in the VAR
file, the '-p' reports as if all is ok, I only receive the error

ERROR: Unable to connect to sqlite3 database:
/geo/grassdb/ellas/oiti/wgs84_old/PERMANENT/tgis/sqlite.db
Exception: "unable to open database file"
Please use t.connect to set a read- and writable temporal database
backend

from any of the t.connect or t.create commands I tried.

> > 2) although I remove strds-es via t.remove, the command `t.list rast` still
> > shows maps which do not exist anymore anywhere. How come?

Oh my, I think I've asked that again in the past, apologies.


> Maps can be registered in several different STDS. Hence removing a
> STDS without explicitly removing the registered map layers (forced
> with -rf) will only un-register the maps from the specific STDS but
> not from the temporal database.
> Use t.unregister to simply un-register map layers from the temporal
> database (and all associated STDS) or use the -rf option in t.remove
> to fully remove map layers from the temporal and spatial database. The
> module g.remove will not delete the time stamps from the temporal
> database, since only temporal commands are aware of it. The module
> t.support allows to check STDS for removed or overwritten map layers
> to update the temporal database accordingly.

Yet, what if g.remove is used anyhow for a series of registered maps.
How will unregister work it the maps don't exist anymore? t.remove -rf
doesn't do it.  I mean, t.remove expects some strds, for example, to
operate, right?  And t.support the same.

Maybe this has been also answered by you in this previous mail in the
list (I can hardly recall -- will search).

Thanks for your patience, Nikos