Hi Nikos, 2015-02-18 10:58 GMT+01:00 Nikos Alexandris <[email protected]>: > Hi, > > creating a map with > > t.rast.series ols output=ols_sum method=sum > > gives the map which is listed normally via > > 1) g.list rast & 2) t.list rast > > > Removing the map via > > g.remove rast name=ols_sum -f > > is not reflected in t.list rast > > > Shouldn't this be updated in tgis' data base?
Only temporal commands can update the temporal database. The module g.remove does not know anything about the temporal framework, hence g.remove and all other general/spatial commands are unable to update the temporal database. Implementing temporal database management in the existing C modules is tricky, since the temporal framework is implemented in Python. More critical is, that many temporal modules use spatial and general modules in their processing task. Hence, there are problems regarding recursion, performance and concurrent temporal database read/write access. Which module should unregister map layer in case they get overwritten within the temporal module? The temporal module that was called or the spatial module that was used by the temporal module? How does a spatial module know when to unregister a map from the temporal database? Should it do it always, or only when it is not called from a temporal module? The temporal modules will try to gather all the information about overwritten, registered and unregistered map layers and perform the temporal management tasks (register, unregister, update, ...) much, much more efficient then multiple single spatial module calls. Hence, it is a design decision regarding performance with the drawback of more user responsibility about data handling. As a result you need to use t.unregister to manually unregister the map from the temporal database. > > Thanks, Nikos > _______________________________________________ > grass-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-dev _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
