Downloaded tif gets cropped (preprocessing jpgs smaller than tif resolution)

[ArtificialTruth]

Describe the bug

When downloading images from Google Earth Engine, the .tifs get downloaded. For example:

2016-08-22-16-00-42_S2_ID_gmd58_datetime11-18-25__11_19_01_ms.tif
width=996
height=996

Then a .jpg gets created in preprocessing, for example this jpg corresponding to the .tif above:

width=996
height=996

Normally I would not expect the .tiff to get cropped, as seen in above 2 examples, ie same width and height.

But for some ROIs, the tifs get cropped, for example

2017-08-24-15-50-28_S2_ID_gmd66_datetime11-20-25__05_50_14_ms.tif
width=996
height=996

get cropped to

width=996
height=636

Steps To Reproduce

Steps to reproduce the behavior:

1. Select bbox around west coast greenland
2. Set ROIs to be from 0 to 98 km²
3. The config.json explains how it was downloaded using 1_download_imagery.py

Several ROIs jpgs are being cropped, causing overall coastline to have missing areas:

## Expected behavior It is expected to not crop only some ROIs, and then be able to predict the missing coastline in above screenshot.

Screenshots

ALL software version info

Desktop (please complete the following information):

• OS: Ubuntu Desktop
• Version 22
  coastseg 1.4.3 pyhd8ed1ab_0 conda-forge

Additional context

To clarify, here's the folder structure of the problematic tif

[ArtificialTruth]

Note I tried to select the same BBOX and set the ROI size to 30 instead of 98.
Then I tried to redownload the problematic photos, but this did not complete, since it logged they already exist:

ROI:
ROI IDs: ['ogy156', 'ogy157', 'ogy158', 'ogy159', 'ogy160', 'ogy161', 'ogy162', 'ogy163', 'ogy164', 'ogy165', 'ogy166', 'ogy167', 'ogy168', 'ogy169', 'ogy170', 'ogy171', 'ogy172', 'ogy173', 'ogy174', 'ogy175', 'ogy176', 'ogy177', 'ogy178', 'ogy179', 'ogy180', 'ogy181']
ROI IDs with extracted shorelines: 
ROI IDs with shoreline transect intersections: []
 gdf:
CRS: EPSG:4326
Columns and Data Types:
id            object
geometry    geometry

First 5 Rows:
       id                                                                                                        geometry
0  ogy156  POLYGON ((-56.25355 72.83353, -56.25148 72.88263, -56.08477 72.88195, -56.08731 72.83285, -56.25355 72.83353))
1  ogy157  POLYGON ((-56.08731 72.83285, -56.08477 72.88195, -55.91808 72.88113, -55.92108 72.83204, -56.08731 72.83285))
2  ogy158  POLYGON ((-55.92108 72.83204, -55.91808 72.88113, -55.75141 72.88018, -55.75488 72.83109, -55.92108 72.83204))
3  ogy159     POLYGON ((-55.75488 72.83109, -55.75141 72.88018, -55.58476 72.87909, -55.58869 72.83, -55.75488 72.83109))
4  ogy160        POLYGON ((-55.58869 72.83, -55.58476 72.87909, -55.41814 72.87786, -55.42252 72.82878, -55.58869 72.83))
ROIs not downloaded: []
All ROIs are already downloaded

[2320sharon]

Hi @ArtificialTruth thanks for reporting this issue and for documenting everything nicely. I'll attempt to replicate your issue and try to get back to you with a solution as soon as I can. My suspicion is that it got cropped because the initial 98 km ROI size was a bit too large. Most users use between 20 -30km^2.

As for the second issue you mentioned here. I'll try to replicate this behavior and get back to you. Since the filenames are the same CoastSeg skips downloading them since the files already exist, however this is not what you wanted since you need them in a different size. This is technically the correct behavior but since the ROI IDs appear to be different I'm not sure why its doing this. Did you load the old session before you tried the new downloads it could be confusing the ROI IDs?

In the meantime, you could move these files out of coastseg and then download the ROIs again with the new size. This should help while I'm investigating these issues.

[ddbuscombe]

I think we should limit the allowable ROI size to something like 25 square kilometers. The deep learning models use 512x512 pixel images. That's 5.12 sq km for a typical Sentinel scene, and 15.36 sq km for a Landsat 5 scene.

It makes no sense to use something larger, only it makes workflow more convenient. 98 sq. km ROI is crazy large! That's obviously going to cause issues with any algorithm. Learn how the algorithms work, they are well documented

[ddbuscombe]

If we don't do this, we'll have no chance of knowing how much error is due to inappropriate ROI size, and SDS will continue to suffer greatly from massive errors nobody can be bothered to explain

[ArtificialTruth]

Hi,
Thanks for the quick and helpful response.
Downloading the 30 km² did not solve the problem (i deleted the data folder and redownloaded smaller tiles)
The jpgs still get cropped.

[2320sharon]

Hey @dbuscombe-usgs sorry for the late response.
I got got up with a weird issue where the tide model was not downloading correctly for some users.
I think you're right. I'll limit the max ROI size controls down either 25km^2 to 30km^2 in the next update.

[2320sharon]

@ArtificialTruth hmmm that's strange I'll look into the codes that save the jpegs.