Opening S2 files overlapping two distinct UTM zones

It seems that Sentinel-2 images that belong to two UTM zones cannot be displayed entirely with SNP. Upon file opening, the user is to select which UTM zone he wants, and only the part of the image which is strictly within the selected zone will be displayed.

I was wondering whether an option that would automatically reproject one side of the image to the other side’s projection is considered in a future release to visualise the whole image?

Another solution could be to provide the user with the option of having SNAP reproject everything to Geographic projection prior to opening. This way we would get rid of the UTM zone issue.


Hi Daniel,

I have the same problem. Has this issue been answered since?

Here’s an example using the image S2A_OPER_PRD_MSIL1C_PDMC_20150829T215845_R108_V20150829T104425_20150829T104425.SAFE

that covers 2 UTM zones.

When I open it with SNAP, I’m only able to see the left side of the image, which correspond to one UTM zone.
However, using gdalwarp, I can merge all granules together, and the overlaying image you can see is the result I get.

Moreover, has anyone else realised that the images delivered by ESA sometimes contains twice the same info, due to this UTM zone issue? I think this happens particularly for images over polar areas where the zones tend to overlap more.
As an example, you can look at image S2A_OPER_PRD_MSIL1C_PDMC_20151226T235102_R099_V20151226T200904_20151226T200904.SAFE.
Granules T55CEK and T56CMQ contains an image of the same area, just in a different projection…


I have experienced the same issue.

I would like to ask to the developers that will modify the snap configuration so once you decide to open the S2A data in native, 10m, 20m, 60m resolution in one or other UTM zones, it will open the entire product in the selected UTM zone instead to have to work with half image.

What happens if your AOI is exactly in between of two different UTM zones?

Thanks in advance.
Best regards

Hi mdelgado,

as far as I am concerned, only the UTM zone in the western and central part of the image (UTM N37) opens, not the eastern (N38). I have no example of an image in which the zone boundary is located right at the centre of the image.

Your suggestion to developers: selecting resolution + choice of opening everything in a single UTM zone is excellent. Go ahead with your request!

Actually having the option of opening in a UTM zone that is in not at all in the image could be useful too - for instance, keeping the example of my image in which N37 and N38 overlap, I could be interested in selecting N36 or N39 if I want to include this in a large mosaic. Not mandatory, just convenient.


I agree with all of you. Would be really useful! At the moment I try to overcome this issue while implementing an automatic reprojection into a python script. It should work, but I can not test it at the moment because of lack of memory on my desktop computer. :disappointed:

Hi all,

any progress on this topic?
mdelgado, did you send your request to the developers?



Has there been any solutions for this issue ? I’m working on an area across UTM zones and it is making the creation of timeseries composites problematic using tools like sen2three.

I guess Ineed to reproject (and resample?) to a common coordinate system but would welcome any suggestions / advice about this - and any limitations it is likely to place on later analysis in SNAP?

Many thanks

This is, or was, an issue with older S2A products. Meanwhile they don’t span several UTM zones anymore.
You can use the mosaic tool to combine several UTM zone to one data product. But this should be the last step I think.
First do Sen2Three and afterwards you can do mosaicking. There is a special S2Mosaic operator, this handles the different resolutions of Sentinel-2 properly. If you would do the mosaicking beforehand, Sen2Three will not work with mosaicked data, I guess.

Many thanks Marpet for the reply. I think your approach is correct - in terms of Sen2Three first. I assume by S2Mosaic operator you’re referring to the multi-size mosaicing? One restriction of multi-size mosaic is it doesn’t appear to work on a mix of Sen2Three outputs and original 2A products.
More generally I’m wondering if there is a way one can edit/define the masks that define which pixels are considered valid by multi-size mosaic - perhaps a Q for a new thread?

Yes, it would be good if you can open a new thread. I think it is worth it.