[GRASS-dev] Removed raster produced by t.rast.series still in t.list rast

[Sören Gebbert]

Hi Nikos,
be aware that t.rast.series will only attach a time stamp to the
resulting raster map (that means it will put it into the temporal
database as a time stamped map layer), but it will to register it in
any space time raster dataset. Hence, use t.unregister without the
input option, since the map is only registered in the temporal
database but not in a space time raster dataset:

t.unregister maps=ols_sum


Best regards
Soeren

2015-02-18 11:50 GMT+01:00 Nikos Alexandris <nik at nikosalexandris.net>:
> Nikos Alexandris:
>
>>> 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?
>
>
> Sören Gebbert wrote:
>
>> 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.
>
>
> Soeren,
>
> all read and understood.  And that's perfectly fine so.  But I still think
> there is a problem (or a design mis-catch).  Let's get this step-by-step (in
> G71, since it t.create doesn't work for me in G7):
>
> t.connect -d
> t.create type=strds title="DMSP-OLS Sicily" description="Version 4 DMSP-OLS
> Nighttime Lights Time Series over Sicily" output=ols
> t.register -i input="ols"
> maps="F162004,F162005,F162006,F162007,F162008,F162009" start="2004-01-01
> 00:00:00" increment="1 years" --o
> # plus more t.register commands
>
> then
>
> t.rast.series ols output=ols_sum method=sum --o
>
> And now, should the user unregister first, then remove?  Or it doesn't
> matter?  Either way, it doesn't work for me because of:
>
> t.unregister input=ols maps=ols_sum
> 0..WARNING: Map <ols_sum at sicily> is not registered in space time dataset
> <ols at sicily>
>
> This is clearly, as fas as I can understand, not a user's mistake.  Any
> help?
>
> Thank you so much for the insight, Nikos