Closed jdries closed 1 year ago
It seems to work for cgls collections, so specific to shub?
This specific collection has features with a bounding box that is not valid in EPSG:3035. When doing intersection, this needs to be taken into account. What is interesting here as well is that the Sentinelhub result contains a proj:geometry property. So apparently, we have information about the real CRS as well.
"type": "FeatureCollection",
"features": [
{
"stac_version": "1.0.0",
"stac_extensions": [
"https://stac-extensions.github.io/projection/v1.0.0/schema.json"
],
"id": "a1163ebd-97fa-4750-8a93-25142474eda3",
"type": "Feature",
"geometry": {
"type": "Polygon",
"crs": {
"type": "name",
"properties": {
"name": "urn:ogc:def:crs:OGC::CRS84"
}
},
"coordinates": [
[
[
-56.50514190170435,
72.66326966834433
],
[
-56.50514190170435,
24.284357087313037
],
[
72.90614056172527,
24.284357087313037
],
[
72.90614056172527,
72.66326966834433
],
[
-56.50514190170435,
72.66326966834433
]
]
]
},
"bbox": [
-56.50514190170435,
24.284357087313037,
72.90614056172527,
72.66326966834433
],
"properties": {
"datetime": "2000-01-01T00:00:00Z",
"proj:epsg": 3857,
"proj:bbox": [
-6290123.623699396,
2788096.7398693264,
8115874.443034085,
1.1996485025544627E7
],
"proj:geometry": {
"type": "Polygon",
"crs": {
"type": "name",
"properties": {
"name": "urn:ogc:def:crs:EPSG::3857"
}
},
"coordinates": [
[
[
-6290123.623699394,
1.1996485025544627E7
],
[
-6290123.623699394,
2788096.7398693254
],
[
8115874.4430340845,
2788096.7398693254
],
[
8115874.4430340845,
1.1996485025544627E7
],
[
-6290123.623699394,
1.1996485025544627E7
]
]
]
}
},
"assets": {},
"collection": "byoc-4c5441a6-6040-4dc4-a392-c1317bbd1031",
"links": [
{
"href": "https://creodias.sentinel-hub.com/api/v1/catalog/1.0.0/",
"rel": "root",
"type": "application/json"
},
{
"href": "https://creodias.sentinel-hub.com/api/v1/catalog/1.0.0/collections/byoc-4c5441a6-6040-4dc4-a392-c1317bbd1031/items/a1163ebd-97fa-4750-8a93-25142474eda3",
"rel": "self",
"type": "application/geo+json"
},
{
"href": "https://creodias.sentinel-hub.com/api/v1/catalog/1.0.0/collections/byoc-4c5441a6-6040-4dc4-a392-c1317bbd1031",
"rel": "parent",
"type": "application/json"
},
{
"href": "https://creodias.sentinel-hub.com/api/v1/catalog/1.0.0/collections/byoc-4c5441a6-6040-4dc4-a392-c1317bbd1031",
"rel": "collection",
"type": "application/json"
}
]
}
],
"links": [
{
"href": "https://creodias.sentinel-hub.com/api/v1/catalog/1.0.0/search",
"rel": "self",
"type": "application/geo+json"
}
],
"context": {
"limit": 100,
"returned": 1
}
}```
It's fixed on openeo-dev!
Anyhow…. I was now testing the full UDP candidate and the final raster file has still an issues I didn’t expected. I have empty blocks at the end??? The existing blocks are correctly calculated, but all the lower blocks are nan.
I was testing and figured out that it is again the “resample_spatial()” process! If I do not apply the final resampling and download in the original EPSG (EPSG:3857) then the full data is available (see second picture).
Here the final UDP candidate for creating the arable/non-arable mask: https://git.vito.be/projects/NCA/repos/people-ea/browse/c_factor/arable_mask.py?at=refs%2Fheads%2Ffeature%2FNCAP-1058-fcover-udp
Raster resampled to EPSG:3035 and 100m:
Dataset not warped: