Opened 10 years ago
Last modified 5 years ago
#2363 assigned defect
Temporal datasets in a mapset are not visible when the mapset is renamed
| Reported by: | annakrat | Owned by: | huhabla |
|---|---|---|---|
| Priority: | normal | Milestone: | 7.8.3 |
| Component: | Temporal | Version: | svn-trunk |
| Keywords: | mapset, temporal | Cc: | huhabla |
| CPU: | Unspecified | Platform: | All |
Description
When I create a strds in a mapset and then rename the mapset, the strds is not accessible any more, although it is still in the database. I am not sure if this is a defect or undocumented limitation.
Change History (15)
follow-up: 2 comment:1 by , 10 years ago
follow-up: 3 comment:2 by , 10 years ago
Replying to huhabla:
This is a limitation that is not easy to fix. The module t.list will show only those stds from mapsets you have access to. If you rename a mapset, the ids of the stds will still build upon the original mapset name and therefor this mapset will be unknown to GRASS. Hence, if you rename a mapset you have to access the temporal database by your tool of choice and modify the mapset and id columns of the stds and map tables. In worst case you need to modify 5 tables with SQL staments to rename the mapset.
That's what I thought. The main problem is that it is unexpected. Perhaps the GUI startup dialog could find out if there is temporal database and warn the user before renaming the mapset (using t.connect -pg). It would be of course then nice if there would be some tool to automatically update the database.
comment:3 by , 10 years ago
| Cc: | added |
|---|---|
| Keywords: | temporal added |
| Owner: | changed from to |
| Status: | new → assigned |
Replying to annakrat:
Replying to huhabla:
This is a limitation that is not easy to fix. The module t.list will show only those stds from mapsets you have access to. If you rename a mapset, the ids of the stds will still build upon the original mapset name and therefor this mapset will be unknown to GRASS. Hence, if you rename a mapset you have to access the temporal database by your tool of choice and modify the mapset and id columns of the stds and map tables. In worst case you need to modify 5 tables with SQL staments to rename the mapset.
That's what I thought. The main problem is that it is unexpected. Perhaps the GUI startup dialog could find out if there is temporal database and warn the user before renaming the mapset (using t.connect -pg). It would be of course then nice if there would be some tool to automatically update the database.
Yes that would indeed be handy. Added to my much to long TODO list.
comment:6 by , 8 years ago
| Milestone: | 7.2.1 → 7.2.2 |
|---|
comment:9 by , 7 years ago
| Milestone: | → 7.2.4 |
|---|
comment:10 by , 6 years ago
| Milestone: | 7.2.4 → 7.6.2 |
|---|
comment:11 by , 6 years ago
| Milestone: | 7.6.2 → 7.8.0 |
|---|
comment:15 by , 5 years ago
| Milestone: | → 7.8.3 |
|---|
This is a limitation that is not easy to fix. The module t.list will show only those stds from mapsets you have access to. If you rename a mapset, the ids of the stds will still build upon the original mapset name and therefor this mapset will be unknown to GRASS. Hence, if you rename a mapset you have to access the temporal database by your tool of choice and modify the mapset and id columns of the stds and map tables. In worst case you need to modify 5 tables with SQL staments to rename the mapset.