[GRASS-dev] [GRASS GIS] #2110: error registering maps outside mapset

[GRASS GIS]

#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 huhabla):

 Replying to [comment:4 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.

 If you have a multi-user mapset environment, then you have to take care
 where to put the temporal database that should be accessed by several
 users from different mapsets. You can simply put the temporal database
 into a directory to which your group of users has write permissions? You
 can use PostgreSQL as temporal database, then you have to take care about
 user access permissions at the server as well. You don't depend on the
 default settings. However, i can change the default location of the
 temporal database to be mapset specific if everyone agrees.

 But, changing this default behavior results in the drawback that the
 temporal database will be created for each mapset separately. Hence the
 user will not be able to see space time datasets from other mapsets. This
 is a principal problem of the SQL database Python interface. It is not
 possible to merge several sqlite databases to a single one and open them
 at once. This is AFAIK also not possible with the PostgreSQL backend.
 Different mapsets must share a single database to be able to see the space
 time datasets of each other.
 I would love to see a solution of multi-database management to fix this
 issue.

 The temporal database approach is different from the vector database
 approach, where each vector has its own metadata file that describes the
 database connection for each layer. This approach can not be applied to
 the temporal database design, otherwise i need to create a database
 metadata connection file for each map and space time dataset. Hence if you
 want to access the temporal metadata information for 10000 maps, then you
 need to visit 10000 metadata files, connect 10000 times to the databases
 and read information for each map. Simple SQL where conditions would take
 hours to process. Sorting and many other features would not be available
 as SQL query. This approach would simply not work.

 Hence, if the user wants to access space time datasets from different
 mapsets, then the temporal database path in each of these mapsets must
 point to single writable database location (sqlite -> path, postgresql ->
 server).


 > 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:
 >
 [snip]
 >
 > It is naturally "read-only" because PERMANENT is owned by MarkusN and
 not by me.[[BR]]

 This will fail even if the temporal frameworks allows that you can
 register maps from different locations in a space time dataset in your
 current location.
 In your case the registration process will modify the metadata of the
 raster maps in MarkusN location, it will try to set the time stamps for
 the maps. And because you have no write permission this will fail.

 Space time datasets and their content are mapset specific, maps will be
 modified if you register them in the temporal database. It is IMHO an
 important functionality. It assures that you have access to the map time
 stamps using the C libraries.

 > 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:
 >
 [snip]
 >
 > 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.

 I agree that putting the temporal database by default into the PERMANENT
 mapset might not be the most agreeable solution. But the design decision
 that space time datasets and their content are mapset specific follows the
 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.

 In this case the automated procedure should update the space time datasets
 that manages the time series in the mapset of MarkusM? If the temporal
 database connection of the mapset from MarkusM and your mapset point to
 the same SQL database, then you can access the updated space time
 datasets.

 >
 > 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

 I hope i could explain the design decision a bit better. Of course, if you
 have arguments that make my completely obsolete, then we can change the
 design. But so far i don't see a reason to change this. :)

 Best regards and many thanks for this discussion, we should have had it in
 the design phase of the temporal framework ;)
 Soeren

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2110#comment:5>
GRASS GIS <http://grass.osgeo.org>