-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
load_stac missing data when stiching two tiles #778
load_stac missing data when stiching two tiles #778
Comments
The problem occurs in regions where two features meet and In this case, the |
@jdries is this optimization something that we want to have for Otherwise, the real fix is twofold:
Fixing the footprints will consider both assets and therefore remove the gap: |
I'm not sure if we need the optimization: most products are generated without any overlap. The huge amount of overlap applied to sentinel-2 is rather the exception. In addition to that, we do the optimization for sentinel-2, because it is such a commonly used collection. For load_stac, it is probably better to be on the safe side and load a bit more data. I do believe that we should consider fixing the footprints, and also using the geometry rather than bbox should be a good idea in general. |
@VictorVerhaert is it Stijn C. that is responsible for https://stac.openeo.vito.be/collections/tree_cover_density_2018 or who should I bother? |
@bossie I made that collection myself. |
@VictorVerhaert At least This item for example: https://stac.openeo.vito.be/collections/tree_cover_density_2018/items/TCD_2018_010m_E44N27_03035_v020 reports a {
"type": "Polygon",
"coordinates": [
[
[
11.064548187608006,
47.38783029804821
],
[
11.064548187608006,
48.3083796083107
],
[
12.36948893966052,
48.3083796083107
],
[
12.36948893966052,
47.38783029804821
],
[
11.064548187608006,
47.38783029804821
]
]
]
} whereas I would expect it to be something like: {
"type": "Polygon",
"coordinates": [
[
[
11.046005504476401,
47.40858428037738
],
[
11.707867449704809,
47.40021736186508
],
[
12.36948893966052,
47.38783030409527
],
[
12.390240820693707,
47.837566260620925
],
[
12.411462626880093,
48.28720072607632
],
[
11.738134164531402,
48.29984134090657
],
[
11.064548187608006,
48.30837961418922
],
[
11.055172953154765,
47.85853023272656
],
[
11.046005504476401,
47.40858428037738
]
]
]
} such that it matches the actual footprint of the GeoTiff asset. |
Open-EO/openeo-geopyspark-driver#778 CRS changed from 32632 to 3035 as a result of Open-EO/openeo-geopyspark-driver#781.
Disabled the optimization in case of
|
Open-EO/openeo-geopyspark-driver#778 The quick fix (disable the optimization in case of load_stac) became the real fix so these are essentially cosmetic changes.
When using load stac on the following collection: https://stac.openeo.vito.be/collections/tree_cover_density_2018
(job_id: j-2405173083f249c2bcc9c07be6e65416)
I get the following missing data:
From the load_stac api call
STAC API GET https://stac.openeo.vito.be/search?limit=20&bbox=11.1427023295687%2C47.22033843316067%2C11.821519349155245%2C47.628952581107114&datetime=1970-01-01T00%3A00%3A00Z%2F2069-12-31T23%3A59%3A59.999000Z&collections=tree_cover_density_2018&fields=
i fethed the two matching tiff files (given other color for clarity):
where you can see that the data from the red tile does exist but is not correctly loaded in. (the top line of the missing rectangle corresponds exactly to the dividing line of the two tiles.
used openeo code on CDSE:
The text was updated successfully, but these errors were encountered: