search

yeesian / ArchGDAL.jl

A high level API for GDAL - Geospatial Data Abstraction Library
https://yeesian.github.io/ArchGDAL.jl/stable/
Other
137 stars 25 forks source link

AG.extensiondriver does not return driver for .cog extension #334

Closed maxfreu closed 1 year ago

maxfreu commented 1 year ago

AG.extensiondriver currently doesn't find the COG driver for cloud optimized geotiffs with .cog extension. In some way it makes sense, as they are just regular tiffs with sauce, but maybe one could hack it to make it return the COG driver :)

visr commented 1 year ago

Ha, is, .cog actually used much? I thought most people just use .tif. Right now we just defer to GDAL for this, it probably doesn't make sense to deviate from GDAL for this format only.

https://github.com/yeesian/ArchGDAL.jl/blob/51f22608470e41f9c14e6a3b9372e6719bef9e1a/src/driver.jl#L157-L162

evetion commented 1 year ago

I just use .tif, cog is just an optimized tif, while being backwards compatible.

rafaqz commented 1 year ago

@maxfreu do tiffs with a .cog extension actually exist in the wild?

If so it's pretty easy to hack in Rasters.jl backend detection if that's what you need it for, and maybe going with GDAL defaults is best here.

You can would make a super type for GDALfile called AbstactGDALfile and have COGfile <: AbstractGDALfile. Then add the .cog extension here: https://github.com/rafaqz/Rasters.jl/blob/main/src/convenience.jl

Then add methods for probably _open in gdal.jl and swap everything else to the abstract type.

maxfreu commented 1 year ago

@maxfreu do tiffs with a .cog extension actually exist in the wild?

Actually I don't know. I started to use the extension to make a distinction for files that support http stuff. But as COGs are just regular tiffs and I couldn't find any .cog extension by googling for a while I guess I should reconsider that. I can live without this and it's not important, so I'm closing this. Thanks for the feedback.