Empty MODIS data return for Greenland

Data Sources
1

Hi all,

When I am trying to download MODIS data from Sentinel Hub via WcsRequest I am getting empty frames:

WcsRequest(data_source=DataSource.MODIS,
layer=‘TRUE_COLOR’,
bbox=utm22N_bbox,
time=(‘2016-05-20’, ‘2016-05-30’),
resx=‘500m’, resy=‘500m’,
instance_id=INSTANCE_ID_MODIS)

Where utm22N_bbox has following geometry: Polygon([(380000 , 7690000), (380000, 7770000), (460000, 7770000),(460000,7690000), (380000,7690000)])
and crs: <CRS.UTM_22N: ‘32622’>

INSTANCE_ID_MODIS = ‘a50c9006-9a97-41e2-924d-XXXXXXXXXXXX’

If I changed CRS to <CRS.WGS84: ‘4326’> with code:
wgs84_bbox = utm22N_bbox.transform(CRS.WGS84)
final coordinates: ‘-54.04200364049867,69.29287275517264,-52.049659656172,70.03391818262855’
I am getting images with data along. :slight_smile:

Nevertheless, the picture size is not 160x160px as expected but

165x154px

Do you think it will be possible to download MODIS the data in different UTM projections?
What can I do instead to map raster image after download in CRS.WGS84 projection?
Is transforming to vector, then mapping to preffered UTM, and then transforming back to raster datatype will retain good quality of reference?

edited: I added bbox reference for WGS84 and instance id

Thank you for your help in advance.
Kamil

2

Please provide the instance_id (leave out the last block) so that we can reproduce your issuse.

3

And provide the WGS84 block as well.
The easiest it is for us to reproduce your problem, more chance there are we can see what goes wrong.

4

It is possible now to reproduce the problem?

Best regards,
Kamil

5

My first guess would be that you have to use UTM21N.
Can you give it a try?

6

Ah, I see that this is crossing two zones. It should work however.

7

Hi Grega,

Unfortunately, nothing works. Even, when I am trying to use different code.

Creating SentinelHubWCSInput EO Task:

custom_script = ‘return [B01, B02, B03, B04, B05, B06, B07];’
add_data = SentinelHubWCSInput(data_source= DataSource.MODIS,
layer=‘ALL_RAW_BANDS’,
feature=(FeatureType.DATA, ‘RAW_BANDS’),
custom_url_params={CustomUrlParam.EVALSCRIPT: custom_script,
CustomUrlParam.QUALITY: 100 },
resx=‘250m’,
resy=‘250m’,
maxcc=0.3,
image_format =MimeType.TIFF_d32f,
instance_id = account.INSTANCE_ID_MODIS,
time_difference=datetime.timedelta(minutes=10),
raise_download_errors=True

where , account.INSTANCE_ID_MODIS = ‘a7aa4864-76b1-4575-add1-XXXXXXXXXXXX’

Then I execute it:

eopath = add_data.execute(eopatch=None, bbox=greenland_exemplary_bbox, time_interval=account.DATE_RANGE)

where:
greenland_exemplary_bbox = BBox(((470000.0, 8000000.0), (480000.0, 8010000.0)), crs=EPSG:32622)
account.DATE_RANGE = (‘2017-03-01’, ‘2017-08-31’)

I get EOPatches in return:

EOPatch(
data: {
RAW_BANDS: numpy.ndarray(shape=(184, 40, 40, 7), dtype=float32)
}
mask: {
IS_DATA: numpy.ndarray(shape=(184, 40, 40, 1), dtype=bool)
}
scalar: {}
label: {}
vector: {}
data_timeless: {}
mask_timeless: {}
scalar_timeless: {}
label_timeless: {}
vector_timeless: {}
meta_info: {
maxcc: 0.3
service_type: ‘wcs’
size_x: ‘250m’
size_y: ‘250m’
time_difference: datetime.timedelta(seconds=600)
time_interval: (‘2017-03-01’, ‘2017-08-31’)
}
bbox: BBox(((470000.0, 8000000.0), (480000.0, 8010000.0)), crs=EPSG:32622)
timestamp: [datetime.datetime(2017, 3, 1, 12, 0), …, datetime.datetime(2017, 8, 31, 12, 0)], length=184
)

But they are all empty:
eopath.data[‘RAW_BANDS’]

array([[[[0., 0., 0., …, 0., 0., 0.],
[0., 0., 0., …, 0., 0., 0.],
[0., 0., 0., …, 0., 0., 0.],
…,
[0., 0., 0., …, 0., 0., 0.],
[0., 0., 0., …, 0., 0., 0.],
[0., 0., 0., …, 0., 0., 0.]],

    [[0., 0., 0., ..., 0., 0., 0.],
     [0., 0., 0., ..., 0., 0., 0.],
     [0., 0., 0., ..., 0., 0., 0.],
     ...,
     [0., 0., 0., ..., 0., 0., 0.],
     [0., 0., 0., ..., 0., 0., 0.],
     [0., 0., 0., ..., 0., 0., 0.]],
    ...,

This happend to different Bboxes (not only on the borders of UTM_22N zone)

Do you reccommend to download it in WGS84 and then:

  • vectorize it
  • transform it to UTM_22N
  • and rasteraze again?

Thank you very much for any help.
Best regards,
Kamil

8

It is beyond my knowledge as well. I asked the engineers to look into it and will come back when I have some more information.

1 Like
9

I got an answers from our engineers. It seems that original these MODIS data are using SR-ORG:6974 and our platform is currently missing an exact transformation between SR-ORG:6974 and EPSG:32622, which results in the error.
We are looking in ways to introduce approximate transformation for such cases.
Will update you when this is updated. We can however not commit to the ETA as it is difficult to assess how much time is needed (and we have to manage other priorities as well).

Hopefully it is soon.

Sorry for the inconvenience…

1 Like
10

Thank you for the information and your help Grega!

Best regards,
Kamil

11

Hi Grega,

Is ithe ETA more like a week, month or rather a year time?

Best,
Kamil

12

More than a week, almost certainly less than a year.
You are the first one reporting this issue so it is not high priority. It is an issue though so we need to fix it.

13

Hi Kamil,

note that the system was upgraded and your example should work.

Best,
Grega

14

Hi Grega,

Thank you a lot for your notification.

Now, everything works super fine :slight_smile:

Best,
Kamil