I’m sorry about the delay in getting back to you! I’ve identified the issue and sent the updated spatial datasets to you via email in a google drive folder.
You’re right that the files already had a WGS84/UTM43N projection, but the geometry WKT of the AOI caught my eye:
POLYGON ((72.7472126947801 11.3417560045156,72.9146865231232 11.2872296417993,72.7764232462353 10.4888079020242,72.6128441580863 10.467386830957,72.2662122808181 10.6095448480389,72.0695279010198 10.7380712744418,72.096791082378 10.9503346150161,72.7472126947801 11.3417560045156))
11.3417 are what I would expect for degrees, like what we would expect to find in a WGS84 projection, and so the units of all of your spatial inputs were being interpreted as though they were in meters (because that’s what the projection said they were in), when in fact they were in degrees. A simple reprojection isn’t really possible because of this mismatch.
So, I resolved this by using GDAL to override the source projection and then reproject to UTM43N. By way of example, here is the
gdalwarp command I used to reproject the bathymetry raster and the
ogr2ogr command I used to reproject the AOI:
$ gdalwarp -s_srs EPSG:4326 -t_srs EPSG:32643 -overwrite Lak\ Bath.tif Lak-Bath-UTM43N.tif
$ ogr2ogr -s_srs EPSG:4326 -t_srs EPSG:32643 -overwrite AOI-AKK-UTM43N.shp AOI\ AKK.shp
Using the resulting datasets, I now see the AOI and other spatial layers where I would expect them, covering three islands off the western coast of India:
And the coordinates of the AOI look like what I would expect for this projection:
POLYGON ((254125.857960344 1254718.94691233,272369.021760113 1248549.89513386,256621.56149178 1160317.65958167,238689.864216842 1158078.55300566,200857.831840599 1174121.86551,179453.701474495 1188546.42422444,182662.461821399 1212016.12050799,254125.857960344 1254718.94691233))
And when I run the CV model with these inputs, the issue originally observed is no longer happening
Let me know if you have any questions!