[BUG] Issue with (ETRS89) CRS when exporting to TIFF

[konstantinos2018]

Describe the bug

I have BEAM-DIMAP files which after some processing in SNAP I "convert" them to EOPatch (with their corresponding BBox and EPSG). An example of EOPatch can be seen below:

EOPatch(
  data: {}
  mask: {}
  scalar: {}
  label: {}
  vector: {}
  data_timeless: {
    sigma_VH_dB: numpy.ndarray(shape=(1009, 879, 1), dtype=float32)
    sigma_VV_dB: numpy.ndarray(shape=(1009, 879, 1), dtype=float32)}
}
  mask_timeless: {}
  scalar_timeless: {}
  label_timeless: {}
  vector_timeless: {}
  meta_info: {}
  bbox: BBox(((706718.5069048709, 5054452.053308526), (715508.5069048709, 5064542.053308526)), crs=CRS('25832'))
  timestamp: []
)

After that, I save them as geoTIFF using the following code:

export_tiff = ExportToTiff(feature=(FeatureType.DATA_TIMELESS, feat_name),
                               folder=out_path/'filename.tiff',
                               date_indices=None,
                               no_data_value=no_data_value,
                               image_dtype=np.uint8)
export_tiff.execute(eop_image);

When I import the saved geoTIFF in QGIS it seems that the CRS is kind of partially recognized. What I notice are the following:

To Reproduce Execute the following code and import geoTIFF file in QGIS:

import sentinelhub
from eolearn.core import EOPatch, FeatureType
from eolearn.io import ExportToTiff
import numpy as np

eoptest = EOPatch()
eoptest.data_timeless['product'] = np.ones(shape=(100, 100, 1))
eoptest.bbox = sentinelhub.geometry.BBox(((706718.5069048709, 5054452.053308526), (715508.5069048709, 5064542.053308526)), crs='EPSG:25832')

export_tiff = ExportToTiff(feature=(FeatureType.DATA_TIMELESS, 'product'),
                           folder='/home/test.tiff',
                           date_indices=None,
                           no_data_value=255,
                           image_dtype=np.uint8)
export_tiff.execute(eoptest);

Expected behavior

The expected behavior in e.g., QGIS should have been like the one below:

To reproduce the expected behavior simply change the CRS from EPSG:25832 to EPSG:32632 in the issue reproduction code above:

Environment

No use of virtual environment (e.g., conda, venv etc). Working via a docker container.

Desktop (please complete the following information):

• OS: Ubuntu 20.04
• Browser: Firefox 102.0
• eo-learn version: 0.9.2
• Python version: 3.6.9

Additional context

1. I have tested and reproduced this issue with ETRS89-based UTM projections (25832 and 25834), while in the case of WGS84-based ones everything works as expected.
2. I have exported the BEAM-DIMAP as geoTIFF using SNAP (with GDAL) and I get the expected result.
3. I have used gdalwarp in QGIS to "re-project" the geoTIFF in EPSG: 25832 and I get the expected result.