#2110: error registering maps outside mapset
----------------------+-----------------------------------------------------
Reporter: lucadelu | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Temporal | Version: svn-trunk
Keywords: register | Platform: All
Cpu: All |
----------------------+-----------------------------------------------------
Comment(by lucadelu):
Replying to [comment:1 huhabla]:
> The current behavior is a design decision. Space time datasets accept
only maps from the same mapset for registration. A new space time datasets
will be dedicated to the current mapset. The current mapset is part of its
temporal database identifier. Hence space time datasets from different
mapsets can be stored in the same temporal database. This assures that
mapsets can share the same temporal database.
>
> Space time datasets are new datatypes in GRASS and should behave like
raster or vector maps. Hence these datatypes are mapsets specific. It is
possible to access space time datasets from different mapsets for reading,
if the mapsets share the same temporal database. But it should not be
possible to modify space time datasets from different mapsets.
>
> As default the temporal database will be created in the PERMANENT
directory, so that space time datasets and maps from different mapsets can
be registered there. This allows the read only access to the datasets from
different mapsets in the temporal database. To avoid this, the temporal
database can be set mapset specific. Hence each mapset sees only their
space time datasets and registered maps.
>
I'm not sure that this is the right way to follow because PERMANENT may be
owned by a user differing from the user that is going to create a new
temporal database in the location (think multi-user location!) so there
should arise a write permission problem.
For example, in the location where our group members store MODIS LST data,
when the user MarkusN previously connected his data to the temporal
framework, but myself I also connect to it later (here MarkusN's data are
hence in PERMANENT) I can do that. But when I try to actually create a new
temporal dataset I obtain this error:
{{{
t.connect -d
Default driver / database set to:
driver: sqlite
database: /grassdata/eu_laea/PERMANENT/tgis/sqlite.db
}}}
{{{
t.create out=lst_2003 title=lst_2003 description="LST 2003 dataset"
ERROR: Unable to execute transaction:
INSERT INTO strds_base ( name ,creator ,mapset ,creation_time
,temporal_type ,id ,semantic_type ) VALUES ('lst_2003' ,'lucadelu'
,'lucadelu_test_temporal' ,'2013-10-17 10:33:20.660192' ,'absolute'
,'lst_2003@lucadelu_test_temporal' ,'mean') ;
INSERT INTO strds_absolute_time ( start_time ,end_time ,granularity
,timezone ,id ,map_time ) VALUES (NULL ,NULL ,NULL ,NULL
,'lst_2003@lucadelu_test_temporal' ,NULL) ;
INSERT INTO strds_spatial_extent ( north ,bottom ,west ,top ,proj
,east ,id ,south ) VALUES (NULL ,NULL ,NULL ,NULL ,'XY' ,NULL
,'lst_2003@lucadelu_test_temporal' ,NULL) ;
INSERT INTO strds_metadata ( max_min ,description ,ewres_min ,title
,min_max ,nsres_min ,nsres_max ,number_of_maps ,raster_register
,command ,min_min ,ewres_max ,id ,max_max ) VALUES (NULL ,'LST 2003
dataset' ,NULL ,'lst_2003' ,NULL ,NULL ,NULL ,NULL ,NULL ,'#
2013-10-17 10:33:20
t.create out="lst_2003" title="lst_2003"
description="LST 2003 dataset"
' ,NULL ,NULL ,'lst_2003@lucadelu_test_temporal' ,NULL) ;
Traceback (most recent call last):
File "/home/lucadelu/compilati/grass7/dist.x86_64-unknown-linux-
gnu/scripts/t.create", line 83, in <module>
main()
File "/home/lucadelu/compilati/grass7/dist.x86_64-unknown-linux-
gnu/scripts/t.create", line 79, in main
semantic, None, grass.overwrite())
File "/home/lucadelu/compilati/grass7/dist.x86_64-unknown-linux-
gnu/etc/python/grass/temporal/open.py", line 169, in
open_new_space_time_dataset
sp.insert(dbif)
File "/home/lucadelu/compilati/grass7/dist.x86_64-unknown-linux-
gnu/etc/python/grass/temporal/abstract_dataset.py", line 395, in insert
dbif.execute_transaction(statement)
File "/home/lucadelu/compilati/grass7/dist.x86_64-unknown-linux-
gnu/etc/python/grass/temporal/core.py", line 628, in execute_transaction
self.cursor.executescript(statement)
sqlite3.OperationalError: attempt to write a readonly database
}}}
It is naturally "read-only" because PERMANENT is owned by MarkusN and not
by me.[[BR]]
Another example: I try to create a new temporal DB in another location
which yet does not contain any temporal DB, but the owner of PERMANENT is
again MarkusN, I get this error:
{{{
t.connect -d
Default driver / database set to:
driver: sqlite
database: /grassdata/patUTM32/PERMANENT/tgis/sqlite.db
}}}
{{{
t.create out=lst_2003 title=lst_2003 description="LST 2003 dataset"
Create temporal database: /grassdata/patUTM32/PERMANENT/tgis/sqlite.db
Traceback (most recent call last):
File "/home/lucadelu/compilati/grass7/dist.x86_64-unknown-linux-
gnu/scripts/t.create", line 83, in <module>
main()
File "/home/lucadelu/compilati/grass7/dist.x86_64-unknown-linux-
gnu/scripts/t.create", line 76, in main
tgis.init()
File "/home/lucadelu/compilati/grass7/dist.x86_64-unknown-linux-
gnu/etc/python/grass/temporal/core.py", line 298, in init
create_temporal_database(dbif, database)
File "/home/lucadelu/compilati/grass7/dist.x86_64-unknown-linux-
gnu/etc/python/grass/temporal/core.py", line 371, in
create_temporal_database
os.makedirs(tgis_dir)
File "/usr/lib/python2.7/os.py", line 157, in makedirs
mkdir(name, mode)
OSError: [Errno 13] Permission denied:
'/grassdata/patUTM32/PERMANENT/tgis'
}}}
So, t.create fails because I cannot write there due to the permission
management, say, PERMANENT is not and should not be group writable.
> This decision was made to reduce confusion, to avoid unexpected behavior
and to assure a convenient behavior of the temporal framework in the GRASS
way.
It is unexpected behaviour since it is contrary to the long-term known
GRASS permission management.
> Examples to support this decision:
>
> If you register maps from a foreign mapset in a space time raster
dataset and you remove the maps in the foreign mapset, then the temporal
database might not be aware of these changes, pointing to maps that have
not been unregistered. In all following operations the effected space time
datasets will produce errors.
The same would apply to imagery groups, but this implementation is there
for many years without real problems. Similar also for r.external and
r.reclass.area. It is unavoidable that a user takes care of the data
management. This should not limit the overall usability, hence more
flexibility is better.
> If you use "t.remove" with the "-rf" option, the provided space time
datasets and its registered maps will be removed from the temporal and
spatial database (g.remove will be called). This operation will fail if
the registered maps are from different mapsets.
>
I understand to some extent your design decision but I see here a big
problem for people with a shared data storage infrastructure like in our
group (FEM PGIS).
For example, MarkusM is reconstructing MODIS LST data and he is at this
point the owner of the mapset in which the results are stored. This
mapset's size is of several TB and I have to work with the entire dataset
(time series). We cannot change the owner of that mapset because it is
continuously updated through an automated procedure.
Until now we cannot use temporal framework in our Unit, for my point of
view this is really a limitation. Please consider to add the possibility
to work with maps outside the working mapset and I'll be able to continue
to test the temporal framework.
Thanks
Luca
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2110#comment:4>
GRASS GIS <http://grass.osgeo.org>
