Coastal Vulnerability: 'Could not open ... as a gdal.OF_RASTER'

NatCap Software Support
1

Hi everyone,
I was trying to test out the coastal vulnerability model but I keep running into an error regarding the bathymetry -

Could not open C:/D drive/QGIS/Trial 4\intermediate\wind_wave\Lak Bath_clipped.tif as a gdal.OF_RASTER

I do not understand what this error means. I have downloaded the bathymetry data from GEBCO and have tried extracting data from different years as well, but none seem to get past this error.
My problem is actually very similar to a problem that had occurred with user Nivedha1994 in March, however the thread did not seem to have the solution.

Any help would be much appreciated. Thanks.

InVEST-Coastal-Vulnerability-log-2021-11-22–01_41_12.txt (6.4 KB)

2

Hi @wenzel ,

Looking at your logfile, it looks like the actual error is a few lines up in the logging:

ERROR [errno 6] C:/D drive/QGIS/Trial 4\intermediate\wind_wave\Lak Bath_clipped.tif: File too large regarding tile size. This would result in a file with tile arrays larger than 2GB

This is a very interesting error and not one I’ve seen before! I’m not entirely sure what’s going on, but could you share your bathymetry raster and AOI with me so I can take a closer look at what’s going on? Feel free to email it to jdouglass@stanford.edu if it’s too large to share here.

Thanks!
James

3

Hi James,
Thanks for writing back.
I have uploaded all the files I am using for this run onto a drive folder and sent the link over to your email address.

Thanks,
Wenzel

4

Received!

I’m able to reproduce this error on my end, and I believe the issue here is that your AOI’s projection appears to be in units of degrees. The model requires that the projection be in meters, and the other spatial inputs will be reprojected for you to the projection of the AOI.

From the user’s guide:

Area of Interest (required). This file must be a polygon vector that has a ‘projected’ coordinate system rather than a ‘geographic’ coordinate system and the chosen coordinate system must have units of meters (the Model Resolution input value will inherit the units of this coordinate system).

So then because the model resolution input value inherits the units of the coordinate system, the bounding box is being extended by 31000 degrees on all sides! So naturally this is causing some strange behavior with the spatial library we’re using.

So the most likely solution here is to reproject your AOI to a reasonable projected coordinate system (units of meters preferred) and re-running the model.

Could you try that out and see if it resolves the issue? Please do let us know if it does not.
Thanks!
James

5

Hi James,
The coordinate system that I had exported all the files to was WGS84 / UTM zone 43N (EPSG:32643). In the description it did mention that the units are measured in meters, but maybe this is not the right projection to use. Is there another projection system that you would suggest for the west coast of India that might be better for this run?

Thanks,
Cheers,
Wenzel

6

Hi @wenzel ,

WGS84 / UTM zone 43N should be a fine projection choice. Could you make sure that you reprojected the files and didn’t just define a new projection? In QGIS for a vector this would be: Vector General -> Reproject layer. I wonder if exporting just defined a new projection system which updates the metadata but doesn’t actually transform the geometries.

Cheers,

Doug

7

Hi @jdouglass ,
I tried reprojecting the files. The input layers showed up as WGS84 / UTM zone 43N to begin with, but I reprojected them to the same layer again. The reprojected layers all overlap exactly with the originals. I also tried reprojecting them to EPSG 4326 and that drastically shifted the positions of the layer so I think they actually were already in the right CRS.

I tried running it again with the reprojected files, however the same error persists. Do let me know if there are any other things I could try out.

Thanking you,
Cheers,
Wenzel

8

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))

Coordinates like 72.747 and 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:

Screen Shot 2021-12-02 at 7.20.23 PM
Screen Shot 2021-12-02 at 7.20.23 PM1054×982 49.1 KB

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 :slight_smile:

Let me know if you have any questions!
James

2 Likes
9

Thanks so much @jdouglass. I’m new to gdal so it took me a while to get a hang of its workings. I was able to replicate the reprojections you’ve made, however, I am unable to reproject the Wave watch 3 shapefile which fails returning the following errors.

ERROR 1: Point outside of projection domain
ERROR 1: Failed to reproject feature 108 (geometry probably out of source or destination SRS).
ERROR 1: Terminating translation prematurely after failed
translation of layer WWT (use -skipfailures to skip errors)

The original dataset did not work with the rest of the reprojected data in the CV model and I was unable to troubleshoot these errors. Do let me know if you know of a solution to this issue.

Thanking you,

Cheers,

Wenzel

10

Hi @wenzel , I would recommend using the original WW3 layer provided with the sample data. There is no need to re-project it ahead of time, the model will handle this appropriately for you so long as the AOI is correctly projected & defined.

If the model is still not working with the original WW3 layer, there is probably still an issue with projections of the AOI or another layer. Feel free to upload your log & data again and we’ll take another look.

2 Likes
11

Thanks so much @dave and @jdouglass. The issue seems to have been resolved :smile:

2 Likes
12

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.