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

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.

It is possible now to reproduce the problem?

Best regards,

Kamil

My first guess would be that you have to use UTM21N.

Can you give it a try?

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

Hi Grega,

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

Creating SentinelHubWCSInput EO Task:

custom_script = ‘return nB01, 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: 8datetime.datetime(2017, 3, 1, 12, 0), …, datetime.datetime(2017, 8, 31, 12, 0)], length=184

)

But they are all empty:

eopath.datat‘RAW_BANDS’]

array( /><0., 0., 0., …, 0., 0., 0.],

r0., 0., 0., …, 0., 0., 0.],

,0., 0., 0., …, 0., 0., 0.],

…,

b0., 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

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.

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…

Thank you for the information and your help Grega!

Best regards,

Kamil

Hi Grega,

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

Best,

Kamil

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.

Hi Kamil,

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

Best,

Grega

Hi Grega,

Thank you a lot for your notification.

Now, everything works super fine

Best,

Kamil