[GRASS-dev] Filter STDS by spatial index

Veronica Andreo veroandreo at gmail.com
Mon Dec 26 06:13:44 PST 2022


Hi Stefan,

Sorry for my late response here... Yes, that sounds like something useful
to me, with collections of satellite images such a case/problem might be
pretty common. So, having the chance to select/filter only those scenes
(fully) covering the current computational region is a good addition in my
opinion.

Thanks Stefan!

Cheers,
Vero

El mar, 20 dic 2022 a las 5:53, Paulo van Breugel (<p.vanbreugel at gmail.com>)
escribió:

>
>
> On December 14, 2022 15:24:28 Stefan Blumentrath <
> Stefan.Blumentrath at gmx.de> wrote:
>
> 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...
>>
>
> It seems a bit of a corner case, but in fact something I could use, of I
> understand it right.
>
>
>> 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
>>
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20221226/f249995b/attachment.htm>


More information about the grass-dev mailing list