Feature suggestion: list of supported drivers

[tpoisot]

Hi! @gottacatchenall and I were looking for a list of drivers supported by GDAL.jl, and it seems like the only one is part of the test suite (e.g. here).

Would it make sense to stick this array in a variable, that doesn't need to be exported? It would allow other packages to perform checks like driver in GDAL.supported_drivers, for example.

If that makes sense (and after reading #65 I know the set of supported drivers might change), I would be happy to open a PR.

[gottacatchenall]

agreed! and similarly i think a shared const of supported EPSG codes (e.g. to pass to gdalwarp) could benefit GDAL/ArchGDAL.jl

[yeesian]

I haven't translated them into the corresponding code of GDAL.jl, but you can get them via ArchGDAL.listdrivers(). It should be better documented, but just thought I'd let you know in advance of any improvements we can make.

[tpoisot]

Thanks @yeesian, that's perfect for what we need!

[visr]

It's worth noting that for the driver in GDAL.supported_drivers usecase you mentioned, a more direct approach would be to use gdalgetdriverbyname / ArchGDAL.getdriver. If a C_NULL is returned, it is not available.

For listing all drivers, you can loop from over all the drivers by index based on gdalgetdrivercount and gdalgetdriver, which is what ArchGDAL probably does.

[yeesian]

I think the request for EPSG codes is still a valid one; I looked it up and the best I found so far is https://gis.stackexchange.com/questions/300846/get-a-list-of-all-supported-epsg-code-from-ogr -- it will be nice to have a way of making it more accessible. Opened up an issue in yeesian/ArchGDAL.jl#370.

[evetion]

agreed! and similarly i think a shared const of supported EPSG codes (e.g. to pass to gdalwarp) could benefit GDAL/ArchGDAL.jl

@gottacatchenall How would that be useful to you? Do you want to check the validity of your transform?

[gottacatchenall]

@gottacatchenall How would that be useful to you? Do you want to check the validity of your transform?

Yes, for both checking the validity of a transform, and potentially for imposing conditions on what are valid EPSGs to run a model with given the bounding box of the data, e.g. EPSG 32198 is specific to Quebec but can be applied to raster data from anywhere with gdalwarp, so we would like to throwing a warning for inputs that are far from the region a specific transformation is meant for

[evetion]

Yes, for both checking the validity of a transform, and potentially for imposing conditions on what are valid EPSGs to run a model with given the bounding box of the data, e.g. EPSG 32198 is specific to Quebec but can be applied to raster data from anywhere with gdalwarp, so we would like to throwing a warning for inputs that are far from the region a specific transformation is meant for

Ah, that makes sense. Might be good to update the issue, because now it reads like we just want a (very long) list of epsg numbers. We actually want a validity and conform bounds checks.