You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation is having a certain type of data (i.e. roughly having S2, L8, S1 resolutions) in mind. When you use S5P with very coarse resolution though, the default implementation with the 0.0003° radius only returns ~1px. On the other hand, for very high resolution imagery, it returns a relatively large sample.
The implementation should read the metadata and try to get the gsd from it (there are several locations where you can look though). This is usually in meters and can be roughly converted to degrees. In this cases it doesn't need to be overly precise though. Based on that the sample can be more consistently sized.
The text was updated successfully, but these errors were encountered:
In Platform only, there's also openeo:gsd per band, which also gives you x/y information and a unit.
But yeah, reading from the summaries, I assume I'd take the 60 in this case, because it seems better to have a little too much data rather than having just a single pixel ;-)
The current implementation is having a certain type of data (i.e. roughly having S2, L8, S1 resolutions) in mind. When you use S5P with very coarse resolution though, the default implementation with the 0.0003° radius only returns ~1px. On the other hand, for very high resolution imagery, it returns a relatively large sample.
The implementation should read the metadata and try to get the gsd from it (there are several locations where you can look though). This is usually in meters and can be roughly converted to degrees. In this cases it doesn't need to be overly precise though. Based on that the sample can be more consistently sized.
The text was updated successfully, but these errors were encountered: