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.vanbreu...@gmail.com>) escribió: > > > On December 14, 2022 15:24:28 Stefan Blumentrath < > stefan.blumentr...@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@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/grass-dev >> > > _______________________________________________ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev >
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
