pygeoprocessing.get_gis_type should raise an exception if gdal can't open the file

[phargogh]

Throughout pygeoprocessing, we do some basic checking for the case where gdal can't open up a dataset. get_raster_info and get_vector_info both do this, and it's reasonable to expect that get_gis_type would also do this.

[dcdenu4]

Hey @phargogh I was just looking at this and it appears that get_gis_type is designed to return pygeoprocessing.UNKNOWN_TYPE if gdal can not open a file as a raster or vector. Are you proposing that instead of that the function should raise a ValueError like get_raster_info and get_vector_info do?

Internally we use get_gis_type only once in stitch_rasters.

[dcdenu4]

Looks like the following InVEST models also call this function:

• CV
• HQ
• HRA

[phargogh]

Yes, I am proposing that if the raster cannot be opened, it should raise a ValueError consistent with how get_raster_info, get_vector_info and other functions in pygeoprocessing behave. My rationale before was that this behavior is inconsistent with the rest of pygroprocessing, where if we can't open a file with GDAL, we raise an exception. But after looking at it again, I think there's another more subtle implication of the current implementation: files that exist but cannot be opened by GDAL are deemed to have a GIS type of pygeoprocessing.UNKNOWN_TYPE. So if someone, say, tries to get the GIS type of a Microsoft Word file, it has an 'UNKNOWN' gis type? I feel like that should be an exception, not a valid return value. Pygeoprocessing only works with GIS files that GDAL supports, so if we can't open it, I think that should be an error.

But this is also a notable behavioral change, and so we might want to put it off until a minor release, which is totally fine by me.