Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am trying to compile a list of file extensions that are accepted by GDAL, something like

['.tif', '.png', '.jpg', '.jpeg', ...]

I found a list of GDAL Raster file formats, but the values in the "code" column in that table are not always file extensions.

Is there a similar table that includes all filename extensions?

The goal is to check if GDAL can open a file from a path that is provided by users.

share|improve this question
up vote 10 down vote accepted

File extensions are mostly meaningless. Sure, they might indicate the file's format but you can easily rename a .exe file to .txt and the file would not change itself. File extensions are mostly used for ease of usage and on some operating systems to decide what to do (which program to launch) if a user tries to "open" a file. Opening an .exe file that was renamed to .txt will lead to confusion because the file format itself is not text.

GDAL supports formats, not file extensions. Some formats have various common extensions, others might even not have any standards.

Instead of checking file extensions, use something like a try/except statement to determine if gdal can open the input file.

share|improve this answer
    
I am not sure if I agree that file extensions are completely meaningless, but you are right that they are not a reliable way of determining file types. – yellowcap Jan 5 at 15:22
    
aye, added some more sentences – bugmenot123 Jan 5 at 16:21
    
I agree that saying they're meaningless is going a bit far. What I would say is that they are a convention only, and that anyone and any software is free to violate the conventions. – jpmc26 Jan 6 at 3:33

To get a list of format names and common extensions use:

from osgeo import gdal
for i in range(gdal.GetDriverCount()):
    drv = gdal.GetDriver(i)
    if drv.GetMetadataItem(gdal.DCAP_RASTER):
        print(drv.GetMetadataItem(gdal.DMD_LONGNAME), drv.GetMetadataItem(gdal.DMD_EXTENSIONS))

Output snippet:

('Virtual Raster', 'vrt')
('GeoTIFF', 'tif tiff')
('National Imagery Transmission Format', 'ntf')
('Raster Product Format TOC format', 'toc')
('ECRG TOC format', 'xml')
('Erdas Imagine Images (.img)', 'img')
('CEOS SAR Image', None)
('CEOS Image', None)
('JAXA PALSAR Product Reader (Level 1.1/1.5)', None)
('Ground-based SAR Applications Testbed File Format (.gff)', 'gff')
('ELAS', None)
('Arc/Info Binary Grid', None)

That is assuming you only want raster formats, and are using GDAL 2.0+. If you are using 1.x you can omit the DCAP_RASTER test. This is commonly used in 'Open...' or 'Save As...' dialogs for recommended names. If you are doing a 'Save As...', you have to check for the appropriate metadata option for Create() or CreateCopy()(DCAP_CREATE/DCAP_CREATECOPY).

Apologies if my code is non-pythonic, I rarely use it. If you'd like a specific answer for a specific version, please post your gdal version.

share|improve this answer
    
Your code is more or less fine. You're largely constrained by the GDAL API itself, so unless you plan to write wrapper code that follows the norms of the language a bit more (which for an application that would have to be maintained, I probably would), this is what you have to do. Even with the wrapper code, you're going to do something similar to this in the guts of it, anyway. The only thing I'd really advise changing would be to split the extension string on space, so you have a list of extensions. That would require testing for edge cases like None, though. – jpmc26 Jan 6 at 3:37

If you are trying to answer the question "Will the user be able to open the dataset with GDAL?" by comparing it to a precompiled list of file extensions (or even datasets for that matter) you will be in big trouble for two reasons:

  1. As @bugmenot123 pointed out the file extension might differ from the raster filetype and even more importantly a lot of extensions overlap / are used by different formats (e.g. .hdf, .bil).

  2. The amount of formats GDAL can handle depends largely on how it was compiled. Lots of drivers require external libraries to work and if GDAL wasn't compiled with them it won't be able to open the dataset (again .hdf HDF5 is a prominent example). There is no one definitive GDAL installation but it very likely differs from user to user.

One way to solve this is by trying to open the dataset and see if GDAL can handle it (as @bugmenot123 pointed out with try/except).

from osgeo import gdal
gdal.UseExceptions()  
try:
    gdal.Open("/user/provided/path/Geotiff.tif")
except:
    print "not a supported dataset"
share|improve this answer

For those using the node-gdal bindings for Node.js:

const gdal = require('gdal');
const extensions = [];
gdal.drivers.forEach(driver => {
    const exts = driver.getMetadata().DMD_EXTENSIONS;
    if (exts) {
        exts.split(' ').forEach(ext => extensions.push(ext));
    }
}); 
share|improve this answer

The GDAL raster format list already contains file extensions in the Long Format Name column. In the cases extensions aren't mentioned, it is because there are no defined extensions.

share|improve this answer
1  
I believe the original poster is looking for a spreadsheet or listing of extensions themselves that can be consumed by a script. For example, Arc/Info ASCII Grid does not have any reference to it's actual extension (.asc) in that document. – MaryBeth Jan 5 at 19:44

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.