temporal: update raster map metadata from file DB when overwrite is true

[ninsbl]

Currently, metadata like e.g. "creation_time" is not updated, when e.g. a raster map is re-created and then attempted to be re-registered. Metadata is loaded from the temporal DB (map_object.select()) and then written back to the temporal DB.
So, currently, metadata is not updated...

This PR forces reloading of map metadata from the file DB, when a map is in the temporal DB and registered again with overwrite true...

May require more documentation and a unit test...

Syntax is updated to be less Python2 like (replaced % string formating)...

[ninsbl]

After digging a bit more, I see that the actual issue is that the creation time is not loaded from the GRASS map:
https://github.com/OSGeo/grass/blob/main/python/grass/temporal/space_time_datasets.py#L396-L462

However, that indicates that creation_time for e.g. a raster map in TGIS rather means registration_time ...
In my use case I want to select all maps created after or during a given time. So for me creation_time should mean what it says (and not registration_time ). When the map was registered seems of relatively little value, esp. if other properties can get updated later on...

Is it OK if I change the content of that attribute to represent what it actually says it represents? Or does it have to remain to mean registration_time. Are there any use cases for the latter? Or would that be considered API break?

[ninsbl]

Anyone with an opinion or with capacity to review?

[echoix]

I've read through. I can only pronounce myself on the Python itself. I can't comment on the correct usage of the other functions (C and Python) of the project, on the correct kind of implementation, the correct location of the new code, if the tests test the good thing, or the need itself for these changes. Another one would need to approve these other aspects.

[veroandreo]

Anyone with an opinion or with capacity to review?

I am not sure I understand the use case right. Let's say for eg. last year you estimated annual anomalies using a long term mean and sd map. By the end of this year, you'll need to estimate new long term mean and sd maps and recalculate all annual anomalies. In that case all annual anomalies and long term maps would be different from those before even if they keep the same name, so I would expect they change the creation time indeed... for the registration time though, I'm not sure... it will be the same map name, but not the same map...

Which is your use case?

[ninsbl]

Which is your use case?

My use-case are satellite images.

If I download all images ingested yesterday, I may get images with a sensing time up to a month back in time (or even more in case something is re-processed).
In subsequent TGIS processes, I then want to use all new images, without keeping track of all dates that were affected by a download... Therfore I intended to use creation_time (when maps were written to GRASS GIS DB)).
And in case if maps are updated (overwritten) currently creation_time is not updated. So TGIS does not allow to select maps that way consistently...

[veroandreo]

Which is your use case?

My use-case are satellite images.

If I download all images ingested yesterday, I may get images with a sensing time up to a month back in time (or even more in case something is re-processed). In subsequent TGIS processes, I then want to use all new images, without keeping track of all dates that were affected by a download... Therfore I intended to use creation_time (when maps were written to GRASS GIS DB)). And in case if maps are updated (overwritten) currently creation_time is not updated. So TGIS does not allow to select maps that way consistently...

I see, makes sense to me.

[ninsbl]

Forgot to mention, once the map is registered, creation_time is never updated and I can no longer select maps that were updated that way...

[veroandreo]

I now tested re-registering a map with and without this PR, and I see how the creation_time changes... It does not set the right date though, I hope that's something in my laptop only 😲

t.register input=tempmean maps=2012_12_tempmean --o

t.rast.list tempmean columns=id,creation_time
2012_09_tempmean@climate_2000_2012|2024-04-07 11:50:49.950740
2012_10_tempmean@climate_2000_2012|2024-04-07 11:50:49.955943
2012_11_tempmean@climate_2000_2012|2024-04-07 11:50:49.961503
2012_12_tempmean@climate_2000_2012|2024-04-13 11:42:11

[ninsbl]

It does not set the right date though, I hope that's something in my laptop only 😲

Can you post the output of r.info -e 2012_12_tempmean@climate_2000_2012 ?

[veroandreo]

It does not set the right date though, I hope that's something in my laptop only 😲

Can you post the output of r.info -e 2012_12_tempmean@climate_2000_2012 ?

Date remains unchanged there, should it change as well?

GRASS nc_basic_spm_grass7/climate_2000_2012:~ > r.info -e 2012_12_tempmean
map=2012_12_tempmean
maptype=raster
mapset=climate_2000_2012
location=nc_basic_spm_grass7
project=nc_basic_spm_grass7
database=/home/vandreo/grassdata
date="Sat Apr 13 11:42:11 2024"
creator="vandreo"
title=""
timestamp="1 Dec 2012 00:00:00 / 1 Jan 2013 00:00:00"
units=degree Celsius
vdatum="none"
semantic_label=None
source1=""
source2=""
description="generated by r.in.gdal"
comments="r.in.gdal --overwrite input="2012_12_tempmean.tif" output="2012_12_t\empmean" memory=300 offset=0 num_digits=0"

[ninsbl]

Thanks, @veroandreo Looks like creation_time for that map is set correctly. With this PR creation_date in the TGIS database reflects date (creation time) in the file database, and thus should be equal to that. And that seems to be the case in your test as well, no?

[ninsbl]

Seems the latest commit dismissed your previous approving reviews...

[nilason]

@ninsbl You are free to merge!

[ninsbl]

Thanks, @nilason