grass.temporal: Do not fail when registering maps with missing range file #2382
Conversation
ninsbl
added
bug
|
The failing OSGeo4W test is unrelated. |
| return None | ||
| if ret == 2: | ||
| if ret < 0 or ret == 2: | ||
| logging.warning(_("Unable to read range file")) |
There was a problem hiding this comment.
Setting the values seems fine, but the warning text is technically not correct for ret == 2:
https://grass.osgeo.org/programming7/defs_2raster_8h.html#a9efe2d261c71822b99f546c6d740395c
I know this is fairly minor, but still...
There was a problem hiding this comment.
Right. Addressed in faab6c1. Could probably be solved with less code duplication, but I am not sure it is worth doing bigger changes here...
|
Why exactly do you want to support |
When using GDALs /vsicurl/ to link online raster data resources, even the For the addon I have been working on (https://github.com/ninsbl/t.rast.import.netcdf) I may be able to create a range file from a known "valid range" of the data. Could that be helpful to avoid processing errors down the road?
Is there somewhere documentation which kinds of modules require a range file? My usecase is having a set of linked data in a time series to spatio-temporal select from it for further processing. Do e.g. r.mapcalc, r.series, r.univar have problems when a range file is missing? I can imagine that r.colors can run into issues... Maybe with a warning, we can allow people to risk shooting themselfs in the foot also here, as |
See #2381 for some tests and analysis. |
…Geo#2382) * dont fail with missing range file * handle empty range separate
…Geo#2382) * dont fail with missing range file * handle empty range separate
wenzeslaus
changed the title
…Geo#2382) * dont fail with missing range file * handle empty range separate
If maps are linked to the GRASS GIS database with
r.external -rthose maps do not have a range file.When trying to register them in a STRDS, the process fails because no map info is returned at all, meaning no north, south, ... info either. In consequence, NON-NULL constraints of the TGIS DB are violated.
This PR fixes the inconsistency, so I tagged it as a bug and added a backport label. If others feel different about it, please feel free to change the labels.
In case of a missing range file, now None/NULL is returned as range of map values together with a valid spatial extent.