[GRASS-dev] Filter STDS by spatial index

[Stefan Blumentrath]

Hi again,

Please see:
https://github.com/OSGeo/grass/pull/2725

It uses east, west, north and south in the where statement to select only maps that overlap with a given spatial extent (e.g. the computatinal region).
I would be happy to get a review of the PR, before proceding to eventual changes of module code...


Cheers
Stefan
 
 
 

Gesendet: Montag, 26. Dezember 2022 um 17:31 Uhr
Von: "Sören Gebbert" <soerengebbert at gmail.com>
An: "Stefan Blumentrath" <Stefan.Blumentrath at gmx.de>
Cc: grass-dev at lists.osgeo.org
Betreff: Re: [GRASS-dev] Filter STDS by spatial index

Hi,
i am not sure if this helps: some t.rast.* commands should support a where statement. Maybe you can use east, west, north and south in the where statement to select only maps that are in a extent that is build in the where statement?
 
Best regards
Sören  

Am Mi., 14. Dez. 2022 um 15:24 Uhr schrieb Stefan Blumentrath <Stefan.Blumentrath at gmx.de[mailto:Stefan.Blumentrath at gmx.de]>:Hei,
 
I do have a use case where I would like to filter maps in a STRDS by spatial extent before e.g. t.rast.univar processes all registered maps.
In particular, I want to process only maps from a STRDS that intersect with the current computational region.
 
The reason is that the maps registered in the STRDS are collections of single scenes of satellite images or collections of smaller mosaics that cover only parts of the total extent of the STRDS.
 
Currently, that does not seem to be supported by TGIS, and I see two options to address that:
    a) patch the scenes together with a given granularity (e.g. daily mosaics), leave GRASS GIS functions untouched and hope that there is some coverage for reasonable region settings. or:
    b) add a spatial filter to the "get_registered_maps"[1] function in abstract_space_time_dataset.py, and then subsequently flags to relevant modules that make use modified function...

For b) I would think that the most efficient way to handle it would be to add a where clause like it was done for the semantic labels? In that case, it may make sense to add an index for north, south, east, and west too, no? Maybe also top and bottom...

My main question, however is if my case is just a corner case, or does some sort of spatial filteing possibility make sense in general / more broadly...

Any feedback is much appreciated, esp. before I evtl. start working on b).

Kind regards,
Stefan

1) https://github.com/OSGeo/grass/blob/main/python/grass/temporal/abstract_space_time_dataset.py#L1604[https://github.com/OSGeo/grass/blob/main/python/grass/temporal/abstract_space_time_dataset.py#L1604]

_______________________________________________
grass-dev mailing list
grass-dev at lists.osgeo.org[mailto:grass-dev at lists.osgeo.org]
https://lists.osgeo.org/mailman/listinfo/grass-dev