TGIS: new module t.copy #1930

metzm · 2021-10-06T13:46:02Z

This new module t.copy creates a copy of a space-time dataset. It can also copy datasets from a different mapset to the current mapset. Optionally, maps registered in the dataset are also copied. By default, only a new space-time dataset is created.
This PR requires PR #1924 to work properly across mapsets.

veroandreo

Nice addition!

temporal/t.copy/t.copy.html

temporal/t.copy/t.copy.py

temporal/t.copy/testsuite/test_t_copy.py

metzm · 2021-10-06T14:07:19Z

@veroandreo Thanks for the instant review!

temporal/t.copy/t.copy.html

griembauer · 2021-10-06T15:28:35Z

temporal/t.copy/t.copy.py

+                        % (maptype, row["name"], mapset)
+                    )
+
+                kwargs = {maptype: "%s,%s" % (row["id"], row["name"])}


I am not familiar with this syntax, what is the maptype parameter in g.copy?

The syntax of g.copy is g.copy [raster=from,to] [raster_3d=from,to] [vector=from,to] .... Here I use kwargs to avoid an if ... elif ... construct. maptype is here one of raster, raster_3d, vector.

temporal/t.copy/t.copy.py

temporal/t.copy/testsuite/test_t_copy.py

griembauer · 2021-10-06T15:43:28Z

temporal/t.copy/testsuite/test_t_copy.py

+        """Remove the temporary region"""
+        cls.del_temp_region()
+
+    def setUp(self):


isn't all of this already done in the setUpClass method?

temporal/t.copy/testsuite/test_t_copy.py

anikaweinmann · 2021-10-07T13:05:30Z

temporal/t.copy/t.copy.html

+If the <em>-c</em> flag is given, the maps of the old space time dataset
+will also be copied to the current mapset, otherwise the original maps
+will be simply registered in the temporal database. The new copies will
+have the same name as the old maps.


What if there is already a raster map with the same name? Does an error occur then, and can I overwrite that with --o?

In this case a fatal error is issued. Maybe overwriting the existing map in case of --o could be allowed?

anikaweinmann · 2021-10-07T13:08:34Z

temporal/t.copy/t.copy.py

+# %option G_OPT_STDS_TYPE
+# % guidependency: input
+# % guisection: Required
+# % options: strds, str3ds, stvds


In other modules like t.create is the default strds.

The default is here also strds, see https://github.com/OSGeo/grass/blob/main/lib/gis/parser_standard_options.c#L884

anikaweinmann · 2021-10-07T13:14:18Z

temporal/t.copy/t.copy.py

+
+    inname = input
+    inmapset = None
+    if "@" in input:


Doesn't there always have to be an @ in the input, because you copy a STRDS from another mapset into the current one?

No, because as for g.copy, you might want to create a copy of a dataset that is already in the current mapset. t.copy tries to follow the behaviour of g.copy.

veroandreo · 2021-10-12T19:44:37Z

I've downloaded the modis_lst mapset grass79 ready which contains the LST_Day_monthly strds, extracted it within NC location and from user1 mapset tried to test t.copy as indicated in the html manual page, however it does not work as expected. This is what I do in mapset user1:

t.upgrade
g.mapsets mapset=modis_lst operation=add

GRASS nc_spm_08_grass7/user1:~ > t.copy input=LST_Day_monthly type=strds output=LST_Day_monthly
ERROR: Space time raster dataset <LST_Day_monthly> not found
GRASS nc_spm_08_grass7/user1:~ > t.list
----------------------------------------------
Space time raster datasets with absolute time available in mapset <modis_lst>:
LST_Day_monthly@modis_lst
  
GRASS nc_spm_08_grass7/user1:~ > t.copy input=LST_Day_monthly@modis_lst type=strds output=LST_Day_monthly
ERROR: Only maps from the same mapset can be registered
GRASS nc_spm_08_grass7/user1:~ > t.list
----------------------------------------------
Space time raster datasets with absolute time available in mapset <user1>:
LST_Day_monthly@user1
Space time raster datasets with absolute time available in mapset <modis_lst>:
LST_Day_monthly@modis_lst

It only gets copied with full name, not as indicated in the manual page. Could the error be removed? It's misleading.

In any case, the copied strds is empty:

GRASS nc_spm_08_grass7/user1:~ > t.rast.list LST_Day_monthly@user1
ERROR: Space time raster dataset <LST_Day_monthly@user1> is empty

Is this the desired behaviour? What's the point of making a copy if it will be empty? Should it read the maps from modis_lst?

Then, when using -c, I get:

GRASS nc_spm_08_grass7/user1:~ > t.copy input=LST_Day_monthly@modis_lst type=strds output=LST_Day_monthly -c
Copying raster <MOD11B3.A2015001.h11v05.single_LST_Day_6km@modis_lst> to
current mapset as <MOD11B3.A2015001.h11v05.single_LST_Day_6km>
Traceback (most recent call last):
  File "/home/veroandreo/software/grass79-dev/dist.x86_64-pc-linux-gnu/scripts/t.copy", line 241, in <module>
    main()
  File "/home/veroandreo/software/grass79-dev/dist.x86_64-pc-linux-gnu/scripts/t.copy", line 162, in main
    if new_map.is_in_db(dbif, mapset):
TypeError: is_in_db() takes from 1 to 2 positional arguments but 3 were given

metzm · 2021-10-14T07:57:33Z

As I wrote in the description, this PR requires PR #1924 to work properly across mapsets.
The errors

ERROR: Only maps from the same mapset can be registered

and

Traceback (most recent call last):
  File "/home/veroandreo/software/grass79-dev/dist.x86_64-pc-linux-gnu/scripts/t.copy", line 241, in <module>
    main()
  File "/home/veroandreo/software/grass79-dev/dist.x86_64-pc-linux-gnu/scripts/t.copy", line 162, in main
    if new_map.is_in_db(dbif, mapset):
TypeError: is_in_db() takes from 1 to 2 positional arguments but 3 were given

should then dissapear.

veroandreo · 2021-10-14T12:03:50Z

As I wrote in the description, this PR requires PR #1924 to work properly across mapsets. The errors

ERROR: Only maps from the same mapset can be registered

and

Traceback (most recent call last):
  File "/home/veroandreo/software/grass79-dev/dist.x86_64-pc-linux-gnu/scripts/t.copy", line 241, in <module>
    main()
  File "/home/veroandreo/software/grass79-dev/dist.x86_64-pc-linux-gnu/scripts/t.copy", line 162, in main
    if new_map.is_in_db(dbif, mapset):
TypeError: is_in_db() takes from 1 to 2 positional arguments but 3 were given

should then dissapear.

ops... I clearly overlooked that, apologies for the noise then... I'll test properly asap

veroandreo · 2021-10-22T13:10:49Z

I tried once more by downloading the patches and applying them sequentially (first 1924 then this one) and recompiling.

GRASS nc_spm_08_grass7/user1:bin.x86_64-pc-linux-gnu > g.mapsets -p
Accessible mapsets:
user1 PERMANENT modis_lst

GRASS nc_spm_08_grass7/user1:bin.x86_64-pc-linux-gnu > t.list
----------------------------------------------
Space time raster datasets with absolute time available in mapset <modis_lst>:
LST_Day_monthly@modis_lst

GRASS nc_spm_08_grass7/user1:bin.x86_64-pc-linux-gnu > t.copy input=LST_Day_monthly type=strds output=LST_Day_monthly
ERROR: Space time raster dataset <LST_Day_monthly@user1> not found

GRASS nc_spm_08_grass7/user1:bin.x86_64-pc-linux-gnu > t.copy input=LST_Day_monthly@modis_lst type=strds output=LST_Day_monthly
ERROR: Only a map that was inserted in the temporal database can be registered in a space time dataset

GRASS nc_spm_08_grass7/user1:bin.x86_64-pc-linux-gnu > t.list
----------------------------------------------
Space time raster datasets with absolute time available in mapset <user1>:
LST_Day_monthly@user1
Space time raster datasets with absolute time available in mapset <modis_lst>:
LST_Day_monthly@modis_lst

GRASS nc_spm_08_grass7/user1:bin.x86_64-pc-linux-gnu > t.info LST_Day_monthly@user1
 +-------------------- Space Time Raster Dataset -----------------------------+
 |                                                                            |
 +-------------------- Basic information -------------------------------------+
 | Id: ........................ LST_Day_monthly@user1
 | Name: ...................... LST_Day_monthly
 | Mapset: .................... user1
 | Creator: ................... veroandreo
 | Temporal type: ............. absolute
 | Creation time: ............. 2021-10-22 14:38:22.625375
 | Modification time:.......... 2021-10-22 14:38:22.625378
 | Semantic type:.............. mean
 +-------------------- Absolute time -----------------------------------------+
 | Start time:................. None
 | End time:................... None
 | Granularity:................ None
 | Temporal type of maps:...... None
 +-------------------- Spatial extent ----------------------------------------+
 | North:...................... None
 | South:...................... None
 | East:.. .................... None
 | West:....................... None
 | Top:........................ None
 | Bottom:..................... None
 +-------------------- Metadata information ----------------------------------+
 | Raster register table:...... raster_map_register_af21061b02da47fba5fe810894ec64c4
 | North-South resolution min:. None
 | North-South resolution max:. None
 | East-west resolution min:... None
 | East-west resolution max:... None
 | Minimum value min:.......... None
 | Minimum value max:.......... None
 | Maximum value min:.......... None
 | Maximum value max:.......... None
 | Aggregation type:........... None
 | Number of registered bands:. None
 | Band names:................. None
 | Number of registered maps:.. None
 |
 | Title:
 | Monthly LST Day 5.6 km
 | Description:
 | Monthly LST Day 5.6 km MOD11B3.006, 2015-2016
 | Command history:
 | # 2021-10-22 14:38:22 
 | t.copy input="LST_Day_monthly@modis_lst" type="strds"
 |     output="LST_Day_monthly"
 | 
 +----------------------------------------------------------------------------+

GRASS nc_spm_08_grass7/user1:bin.x86_64-pc-linux-gnu > t.copy -c input=LST_Day_monthly@modis_lst type=strds output=LST_Day_monthly
ERROR: Space time raster dataset <LST_Day_monthly> is already in the
database. Use the overwrite flag.

GRASS nc_spm_08_grass7/user1:bin.x86_64-pc-linux-gnu > t.copy -c --o input=LST_Day_monthly@modis_lst type=strds output=LST_Day_monthly
Copying raster <MOD11B3.A2015001.h11v05.single_LST_Day_6km@modis_lst> to
current mapset as <MOD11B3.A2015001.h11v05.single_LST_Day_6km>
Copying raster <MOD11B3.A2015032.h11v05.single_LST_Day_6km@modis_lst> to
current mapset as <MOD11B3.A2015032.h11v05.single_LST_Day_6km>
...

GRASS nc_spm_08_grass7/user1:bin.x86_64-pc-linux-gnu > t.rast.list LST_Day_monthly@user1
name|mapset|start_time|end_time
MOD11B3.A2015001.h11v05.single_LST_Day_6km|user1|2015-01-01 00:00:00|2015-02-01 00:00:00
MOD11B3.A2015032.h11v05.single_LST_Day_6km|user1|2015-02-01 00:00:00|2015-03-01 00:00:00
MOD11B3.A2015060.h11v05.single_LST_Day_6km|user1|2015-03-01 00:00:00|2015-04-01 00:00:00
MOD11B3.A2015091.h11v05.single_LST_Day_6km|user1|2015-04-01 00:00:00|2015-05-01 00:00:00
MOD11B3.A2015121.h11v05.single_LST_Day_6km|user1|2015-05-01 00:00:00|2015-06-01 00:00:00
MOD11B3.A2015152.h11v05.single_LST_Day_6km|user1|2015-06-01 00:00:00|2015-07-01 00:00:00
MOD11B3.A2015182.h11v05.single_LST_Day_6km|user1|2015-07-01 00:00:00|2015-08-01 00:00:00
MOD11B3.A2015213.h11v05.single_LST_Day_6km|user1|2015-08-01 00:00:00|2015-09-01 00:00:00
MOD11B3.A2015244.h11v05.single_LST_Day_6km|user1|2015-09-01 00:00:00|2015-10-01 00:00:00
MOD11B3.A2015274.h11v05.single_LST_Day_6km|user1|2015-10-01 00:00:00|2015-11-01 00:00:00
MOD11B3.A2015305.h11v05.single_LST_Day_6km|user1|2015-11-01 00:00:00|2015-12-01 00:00:00
MOD11B3.A2015335.h11v05.single_LST_Day_6km|user1|2015-12-01 00:00:00|2016-01-01 00:00:00
MOD11B3.A2016001.h11v05.single_LST_Day_6km|user1|2016-01-01 00:00:00|2016-02-01 00:00:00
MOD11B3.A2016032.h11v05.single_LST_Day_6km|user1|2016-02-01 00:00:00|2016-03-01 00:00:00
MOD11B3.A2016061.h11v05.single_LST_Day_6km|user1|2016-03-01 00:00:00|2016-04-01 00:00:00
MOD11B3.A2016092.h11v05.single_LST_Day_6km|user1|2016-04-01 00:00:00|2016-05-01 00:00:00
MOD11B3.A2016122.h11v05.single_LST_Day_6km|user1|2016-05-01 00:00:00|2016-06-01 00:00:00
MOD11B3.A2016153.h11v05.single_LST_Day_6km|user1|2016-06-01 00:00:00|2016-07-01 00:00:00
MOD11B3.A2016183.h11v05.single_LST_Day_6km|user1|2016-07-01 00:00:00|2016-08-01 00:00:00
MOD11B3.A2016214.h11v05.single_LST_Day_6km|user1|2016-08-01 00:00:00|2016-09-01 00:00:00
MOD11B3.A2016245.h11v05.single_LST_Day_6km|user1|2016-09-01 00:00:00|2016-10-01 00:00:00
MOD11B3.A2016275.h11v05.single_LST_Day_6km|user1|2016-10-01 00:00:00|2016-11-01 00:00:00
MOD11B3.A2016306.h11v05.single_LST_Day_6km|user1|2016-11-01 00:00:00|2016-12-01 00:00:00
MOD11B3.A2016336.h11v05.single_LST_Day_6km|user1|2016-12-01 00:00:00|2017-01-01 00:00:00

GRASS nc_spm_08_grass7/user1:bin.x86_64-pc-linux-gnu > t.info LST_Day_monthly@user1
 +-------------------- Space Time Raster Dataset -----------------------------+
 |                                                                            |
 +-------------------- Basic information -------------------------------------+
 | Id: ........................ LST_Day_monthly@user1
 | Name: ...................... LST_Day_monthly
 | Mapset: .................... user1
 | Creator: ................... veroandreo
 | Temporal type: ............. absolute
 | Creation time: ............. 2021-10-22 14:45:40.640974
 | Modification time:.......... 2021-10-22 14:45:40.704268
 | Semantic type:.............. mean
 +-------------------- Absolute time -----------------------------------------+
 | Start time:................. 2015-01-01 00:00:00
 | End time:................... 2017-01-01 00:00:00
 | Granularity:................ 1 month
 | Temporal type of maps:...... interval
 +-------------------- Spatial extent ----------------------------------------+
 | North:...................... 760180.124115
 | South:...................... -415819.875885
 | East:.. .................... 1550934.464115
 | West:....................... -448265.535885
 | Top:........................ 0.0
 | Bottom:..................... 0.0
 +-------------------- Metadata information ----------------------------------+
 | Raster register table:...... raster_map_register_1cf3c995a0e24f188ec8cf624f0a0c44
 | North-South resolution min:. 5600.0
 | North-South resolution max:. 5600.0
 | East-west resolution min:... 5600.0
 | East-west resolution max:... 5600.0
 | Minimum value min:.......... 12950.0
 | Minimum value max:.......... 14714.0
 | Maximum value min:.......... 14360.0
 | Maximum value max:.......... 15650.0
 | Aggregation type:........... None
 | Number of registered bands:. 0
 | Band names:................. None
 | Number of registered maps:.. 24
 |
 | Title:
 | Monthly LST Day 5.6 km
 | Description:
 | Monthly LST Day 5.6 km MOD11B3.006, 2015-2016
 | Command history:
 | # 2021-10-22 14:45:40 
 | t.copy -c input="LST_Day_monthly@modis_lst"
 |     type="strds" output="LST_Day_monthly"
 | 
 +----------------------------------------------------------------------------+

Summary according to testing:

t.copy needs full STRDS name, not as in the example in the manual, otherwise it searches for the STRDS in the current mapset and yields error.
t.copy with the full STRDS name copies the STRDS table but it is empty (t.info reports all None and t.rast.list nothing) and it yields the following error: ERROR: Only a map that was inserted in the temporal database can be registered in a space time dataset. This seems confusing to me as those maps are indeed in the tgis database, only in a diff mapset, which is the core of the problem here.
t.copy only works as I'd had expected if -c flag is set, which does not avoid the data duplication that was the original motivation if I understood it correctly.

Is this the expected behavior?

metzm · 2021-10-24T21:23:42Z

Summary according to testing:

* t.copy needs full STRDS name, not as in the example in the manual, otherwise it searches for the STRDS in the current mapset and yields error.

OK, unfortunately TGIS does not use the mechanism of the GRASS C library to find datae elements.

* t.copy with the full STRDS name copies the STRDS table but it is empty (t.info reports all None and t.rast.list nothing) and it yields the following error: `ERROR: Only a map that was inserted in the temporal database can be registered in a space time dataset`. This seems confusing to me as those maps are indeed in the tgis database, only in a diff mapset, which is the core of the problem here.

TGIS is mapset specific, that is, the existing raster maps in a different mapset must be registered in the TGIS db of the current mapset. Apparently, #1924 does not work as expected.

* t.copy only works as I'd had expected if -c flag is set, which does not avoid the data duplication that was the original motivation if I understood it correctly.

Exactly, the original motivation was to avoid data duplication, to be precise, avoid the need to copy the actual raster maps to the current mapset in order to create a new STDS.

I will have time to take care of these issues by the end of the coming week.

wenzeslaus · 2021-12-15T18:09:11Z

Changing milestone to 8.2.0. Independent and thus can be backported if really needed in 8.0, but as a feature/addtion, it does not need to be in 8.0.0.

metzm · 2022-03-13T21:14:26Z

@veroandreo I have updated the manual and fixed open issues with t.copy. I hope it works now as expected.

The issues mentioned by you:

t.copy needs full STRDS name, not as in the example in the manual, otherwise it searches for the STRDS in the current mapset and yields error.

t.copy with the full STRDS name copies the STRDS table but it is empty (t.info reports all None and t.rast.list nothing) and it yields the following error: ERROR: Only a map that was inserted in the temporal database can be registered in a space time dataset. This seems confusing to me as those maps are indeed in the tgis database, only in a diff mapset, which is the core of the problem here.

t.copy only works as I'd had expected if -c flag is set, which does not avoid the data duplication that was the original motivation if I understood it correctly.

should be resolved by now.

I think that t.copy is an important but so far missing feature in TGIS because g.copy does not support copying space time datasets.

Co-authored-by: Veronica Andreo <veroandreo@gmail.com>

Co-authored-by: Guido Riembauer <62383722+griembauer@users.noreply.github.com>

veroandreo · 2022-03-17T22:41:34Z

Hi @metzm! Great news! I'll test this weekend :)

veroandreo · 2022-03-19T22:03:47Z

All works as expected! Cool!

When using t.copy without full STRDS name, I get an error saying the strds is not found

GRASS nc_spm_08_grass7/user1:grass79-dev > t.copy input=LST_Day_monthly type=strds output=LST_Day_monthly
ERROR: Space time raster dataset <LST_Day_monthly@user1> not found

When I use the full strds name, only the database is copied, since when I list maps in the newly copied strds, mapset is the original one:

GRASS nc_spm_08_grass7/user1:grass79-dev > t.copy input=LST_Day_monthly@modis_lst type=strds output=LST_Day_monthly
GRASS nc_spm_08_grass7/user1:grass79-dev > t.rast.list LST_Day_monthly@user1
name|mapset|start_time|end_time
MOD11B3.A2015001.h11v05.single_LST_Day_6km|modis_lst|2015-01-01 00:00:00|2015-02-01 00:00:00
MOD11B3.A2015032.h11v05.single_LST_Day_6km|modis_lst|2015-02-01 00:00:00|2015-03-01 00:00:00
MOD11B3.A2015060.h11v05.single_LST_Day_6km|modis_lst|2015-03-01 00:00:00|2015-04-01 00:00:00
MOD11B3.A2015091.h11v05.single_LST_Day_6km|modis_lst|2015-04-01 00:00:00|2015-05-01 00:00:00
MOD11B3.A2015121.h11v05.single_LST_Day_6km|modis_lst|2015-05-01 00:00:00|2015-06-01 00:00:00

When I use the -c flag to copy, also maps are copied to the current mapset:

t.copy -c --o input=LST_Day_monthly@modis_lst type=strds output=LST_Day_monthly
Copying raster maps to the current mapset...
Copying raster <MOD11B3.A2015001.h11v05.single_LST_Day_6km@modis_lst> to
current mapset as <MOD11B3.A2015001.h11v05.single_LST_Day_6km>
Copying raster <MOD11B3.A2015032.h11v05.single_LST_Day_6km@modis_lst> to
current mapset as <MOD11B3.A2015032.h11v05.single_LST_Day_6km>
...
GRASS nc_spm_08_grass7/user1:grass79-dev > t.rast.list LST_Day_monthly@user1
name|mapset|start_time|end_time
MOD11B3.A2015001.h11v05.single_LST_Day_6km|user1|2015-01-01 00:00:00|2015-02-01 00:00:00
MOD11B3.A2015032.h11v05.single_LST_Day_6km|user1|2015-02-01 00:00:00|2015-03-01 00:00:00
MOD11B3.A2015060.h11v05.single_LST_Day_6km|user1|2015-03-01 00:00:00|2015-04-01 00:00:00
MOD11B3.A2015091.h11v05.single_LST_Day_6km|user1|2015-04-01 00:00:00|2015-05-01 00:00:00
MOD11B3.A2015121.h11v05.single_LST_Day_6km|user1|2015-05-01 00:00:00|2015-06-01 00:00:00
...

* new module t.copy Co-authored-by: Veronica Andreo <veroandreo@gmail.com> Co-authored-by: Guido Riembauer <62383722+griembauer@users.noreply.github.com>

metzm added enhancement New feature or request temporal Related to temporal data processing labels Oct 6, 2021

metzm added this to the 8.0.0 milestone Oct 6, 2021

metzm requested a review from ninsbl October 6, 2021 13:46

veroandreo requested changes Oct 6, 2021

View reviewed changes

metzm requested a review from veroandreo October 6, 2021 14:06

griembauer reviewed Oct 6, 2021

View reviewed changes

anikaweinmann reviewed Oct 7, 2021

View reviewed changes

wenzeslaus modified the milestones: 8.0.0, 8.2.0 Dec 15, 2021

metzm and others added 10 commits March 14, 2022 18:30

tgis: new t.copy

9953fee

tgis: new t.copy

d4fa736

Update temporal/t.copy/t.copy.html

f12f4d5

Co-authored-by: Veronica Andreo <veroandreo@gmail.com>

Update temporal/t.copy/t.copy.py

e06a359

Co-authored-by: Veronica Andreo <veroandreo@gmail.com>

Update temporal/t.copy/testsuite/test_t_copy.py

ab96b3c

Co-authored-by: Veronica Andreo <veroandreo@gmail.com>

Update temporal/t.copy/testsuite/test_t_copy.py

c8af753

Co-authored-by: Veronica Andreo <veroandreo@gmail.com>

t.copy: fix manual

92c41ae

Update temporal/t.copy/t.copy.html

2296546

Co-authored-by: Guido Riembauer <62383722+griembauer@users.noreply.github.com>

t.copy: improve testsuite

e71424d

fix t.copy

361e361

metzm force-pushed the t.copy branch from 1da6c6e to 361e361 Compare March 14, 2022 17:31

veroandreo approved these changes Mar 19, 2022

View reviewed changes

metzm merged commit 0e34c62 into OSGeo:main Mar 21, 2022

metzm deleted the t.copy branch March 21, 2022 10:55

ninsbl pushed a commit to ninsbl/grass that referenced this pull request Oct 26, 2022

TGIS: new module t.copy (OSGeo#1930)

965a802

* new module t.copy Co-authored-by: Veronica Andreo <veroandreo@gmail.com> Co-authored-by: Guido Riembauer <62383722+griembauer@users.noreply.github.com>

ninsbl pushed a commit to ninsbl/grass that referenced this pull request Feb 17, 2023

TGIS: new module t.copy (OSGeo#1930)

fdc7f68

* new module t.copy Co-authored-by: Veronica Andreo <veroandreo@gmail.com> Co-authored-by: Guido Riembauer <62383722+griembauer@users.noreply.github.com>

neteler pushed a commit to nilason/grass that referenced this pull request Nov 7, 2023

TGIS: new module t.copy (OSGeo#1930)

c2a6a87

* new module t.copy Co-authored-by: Veronica Andreo <veroandreo@gmail.com> Co-authored-by: Guido Riembauer <62383722+griembauer@users.noreply.github.com>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

TGIS: new module t.copy #1930

TGIS: new module t.copy #1930

metzm commented Oct 6, 2021

veroandreo left a comment

metzm commented Oct 6, 2021

griembauer Oct 6, 2021

metzm Oct 6, 2021

griembauer Oct 6, 2021

anikaweinmann Oct 7, 2021

metzm Oct 9, 2021

anikaweinmann Oct 7, 2021

metzm Oct 9, 2021

anikaweinmann Oct 7, 2021

metzm Oct 9, 2021

veroandreo commented Oct 12, 2021

metzm commented Oct 14, 2021

veroandreo commented Oct 14, 2021

veroandreo commented Oct 22, 2021

metzm commented Oct 24, 2021

wenzeslaus commented Dec 15, 2021

metzm commented Mar 13, 2022

veroandreo commented Mar 17, 2022

veroandreo commented Mar 19, 2022

TGIS: new module t.copy #1930

TGIS: new module t.copy #1930

Conversation

metzm commented Oct 6, 2021

veroandreo left a comment

Choose a reason for hiding this comment

metzm commented Oct 6, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

veroandreo commented Oct 12, 2021

metzm commented Oct 14, 2021

veroandreo commented Oct 14, 2021

veroandreo commented Oct 22, 2021

metzm commented Oct 24, 2021

wenzeslaus commented Dec 15, 2021

metzm commented Mar 13, 2022

veroandreo commented Mar 17, 2022

veroandreo commented Mar 19, 2022