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

GRASS GIS GRASS GIS developer
1

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?

Thanks, Nikos

2

Hi Nikos,

2015-02-18 10:58 GMT+01:00 Nikos Alexandris <nik@nikosalexandris.net>:

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
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

3

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@sicily> is not registered in space time dataset <ols@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

4

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@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@sicily> is not registered in space time dataset
<ols@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

5

Sören Gebbert wrote:

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

..

Danke Soeren. Makes sense. Maybe this info can be added in the manual?

Nikos

6

On 18.02.2015 12:27, Sören Gebbert wrote:
..

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.

Soeren,

just another question: how do we move ST-DSes? Is the answer: "we don't!"?
I have created something in the PERMANENT Mapset, while testing. I now want to copy/move this in another Mapset.

Do I need to recreate everything? And what does all this have to do with the "concurrent temporal database read/write access" issue?

Nikos

7

Hi Nikos,

[snip]

just another question: how do we move ST-DSes? Is the answer: "we don't!"?

Exactly! We do not move STDS between mapsets and we don not rename mapsets.

I have created something in the PERMANENT Mapset, while testing. I now want
to copy/move this in another Mapset.

If you insist to do so, then simply write the output of "t.rast.list
input=bla columns=name,start_time,end_time" for each STRDS into
dedicated text files in your source location.
Then rename the mapset or move all raster maps into the new mapset,
re-create the required STRDS and use the text files to register the
maps in the new STRDS.

Don't forget to remove the database in the target mapset, if you have
renamed the mapset.

Easy, isnt it? :wink:

Do I need to recreate everything? And what does all this have to do with
the "concurrent temporal database read/write access" issue?

STDS are mapset specific, you can only register map layers from the
"current" mapset in the mapset specific temporal database.

Best regards
Soeren

Nikos