Some Sentinel-2 L2A images don't have internal georeference info

Some Sentinel-2 L2A images on AWS S3 do not have internal georeference GML box (‘asoc’ box in JPEG2000 file). Thus GDAL cannot process such images correctly, and this brakes the generic workflow

Here’s an example of such a file: https://sentinel-s2-l2a.s3.eu-central-1.amazonaws.com/tiles/34/U/CD/2017/7/30/0/R10m/B04.jp2

On the screenshot I compared the internal structure of the Sentinel-2 L1C and L2A image files. The script I used to parse jp2 files https://github.com/OSGeo/gdal/blob/master/gdal/swig/python/samples/dump_jp2.py ).

How do you handle this problem?

Are those files listed somewhere? so I could use the list to skip “broken” images

Page 1 / 1

In general we recommend to notify EO Support office of ESA/Copernicus about these things to try to solve the problem at the source.

At Sentinel Hub we managed to work around this problem (I see the data in EO Browser) but I do unfortunately not know the technical details on what was done.

Note that JP2 files (raw data) are not changed in the ingestion process at all.

The have fixed this issue around April 2018, but it seems that the older data is still missing its projection. See: Sentinel-2 L2A have no projection info

@gmilcinski do you know if they are planning to add this to the older data aswell?

For older data the issue is probably related to what was discussed in this post:

We are looking into how demanding this exercise would be. It depends also on further evolution of this product. On the side note we are preparing python libraries, which will work around the issue.

There is currently no timeline defined to reprocess the old data.

Thx for your answer. We will just have to work around it for the time being.

We are currently using GDAL directly, so for any1 running into the same issues:

The metadata.xml file in the AWS root directory contains among other things the EPSG and the Tile_Geocoding for each of the resolutions. You can parse these from the metadata.xml and set them using the GDAL functions: ds.SetProjection and ds.SetGeoTransform. GDAL will give a few warnings as it is not able to save these values, but it will generally work fine.

In case anybody tries to override the (unset) georeference with Rasterio: you can use their Virtual Warping module for this:

https://rasterio.readthedocs.io/en/latest/topics/virtual-warping.html

This is the way we implemented it:

WarpedVRT(

src,

crs=crs,

transform=transform,

src_crs=crs,

src_transform=transform,

height=src.height,

width=src.width

)

Where src is the Sentinel 2 image as a Rasterio dataset and crs and transform are the parsed metadata from the mentioned XML.