BYOC tiles visualization issue

EO Products / Scripts
1

Hi there,

I ingested a number of BYOC tiles (several thousand files) into a user collection on CODE-DE. Most of them are working perfectly, meaning I can request them through WMS for visualization purposes. Yet, for some of them, I face visualization issues. For instance, It appears to happen that on a tile at a certain sensing date, data from the underlying file is not shown although there is one available in my collection.

The status for all files in my collection is shown as ‘INGESTED’. For test purposes, I re-ingested one file (certain sensing date) I was having issues with manually, which did the trick in the end.

Is that perhaps a known issue? Or is there a way to find out automatically which of the many files don’t work properly?

Thanks in advance (appologies for my long post)

Patric

2

Hi Patric,

it is not a known issue. We have collections with several millions of tiles and they work fine.

Can you provide a WMS request for one such failed tile (do mask half of the instance ID), so that we can investigate?

Best,
Grega

3

Hi Grega,

thanks so much for your reply!

I think I found the potential issue but don’t know exactly how to solve it.
Neighbouring BYOC tiles have some degree of overlap in my collection due to prior reprojection to EPSG:3857 (original EPSG was 25832). In these overlapping areas, it can happen that actual values from one tile are blocked out from masked values (datamask) located on the neighbouring tile (I guess).

Is there a way to account for such overlaps in the eval. script perhaps? I read something about the ‘mosaicking’ parameter set to ‘tile’. But I don’t know how to implement that in the script in order to select the right tile with actual data.

best wishes,

Patric

4

You first need to ensure that your BYOC tles have “nodata” properly configured, see:

If the above is set correctly, our “SIMPLE” mosaicking option should already do the job, I believe.
If not, you could indeed use mosaicking option and use “dataMask band” in your evalscript.

If the nodata thing does not work for you, give us exemplary WMS request demonstrating this issue and we can take a look for you, to provide more detailed help.

5

Hi Grega,

thanks for providing your valuable help!

This is a WMS query, which should return valid values (for given dates) for a few field parcels, located within an overlapping zone between two BYOC tiles:

https://code-de.sentinel-hub.com/ogc/wms/0ac7e69e-fa69-4237-92cb-xxxxxxxxxxxx?REQUEST=GetMap&BBOX=10.12,54.07,10.18,54.121&LAYERS=DM&FORMAT=image/png&TIME=2020-06-02/2020-06-04&CRS=CRS:84&RESX=10m&RESY=10m

Also, the same query works for other dates e.g. for 2020-06-19/2020-06-22

This is the related eval script (without ‘mosaicking: tile’, I did not manage to solve the issue applying it):

//VERSION=3
ramps = [
[-60, 0xfff0d0],
[60, 0x00cfbf],
];

let viz = new ColorRampVisualizer(ramps);
function evaluatePixel(samples) {
let val = samples.DM;

val = viz.process(val);
val.push(samples.dataMask);
return val;

}

function setup() {
return {
input: [{
bands: [
“DM”,
“dataMask”
]
}],
output: {
bands: 4,
sampleType: “AUTO”,
nodataValue: 0
}
}
}

best wishes,

Patric

6

Hi @Patric,
you were right on guessing it is an issue with overlapping tiles.

I created new layer DM-DEBUG with the following Evalscript

//VERSION=3
ramps = [
  [-60, 0xfff0d0],
  [60, 0x00cfbf],
];

let viz = new ColorRampVisualizer(ramps);
function evaluatePixel(samples) {
  for (i=0;i<samples.length;i++)
  {
	if (samples[i].dataMask)
    {
	  let val = samples[i].DM;
  
	  val = viz.process(val);
	  val.push(samples[i].dataMask);
	  return val;
      
    }
  }
  //if there is no value, let's return empty value
  return [0,0,0,0];
}

function setup() {
  return {
    input: [{
      bands: [
        "DM", 
        "dataMask"
      ]
    }],
    output: {
      bands: 4,
      sampleType: "AUTO" 
    },
    mosaicking: "TILE"
  }
}

It seems to work.

1 Like
7

Thanks a lot Grega, as always of great help! Your script works just perfectly.

best wishes,

Patric