RFC 36: Allow specification of intended driver on GDALOpen

Authors: Ivan Lucena
Contact: ivan.lucena@…
Status: Proposed

Summary

This document proposes a mechanism to explicitly tell GDAL what driver should open a particular dataset.

Justification

By selecting the driver, users can optimize processing time and avoid incorrect or undesirable driver selection due to the driver probing.

Even tough in the driver probing each driver tries to do minimal check on the pre read data and other just need to check some header information on companion files, when running scripts that process a very large number of files that process repeat several times will consumes considerable amount of time.

The other reason is to avoid the situation where an incorrect driver takes over the control and crashes or produce an incorrect or undesirable interpretation of the dataset.

Concept

The idea is to pass the driver name as a hint to GDALOpen at the beginning of the Filename parameter separated from the rest of the information by colons (":"), ex.: "gtiff:example_file.tif" or "hfa:C:\Data\example_file.img".

Implementation

During the GDALOpen process, it will check and parse the driver name on oOpenInfo.pszFilename. If that is a valid driver name it will use the open method of that driver directly, avoiding the probe loop.

Work Plan

A patch was already proposed and have been discussed and improved on ticket #3043. Please look for the latest uploaded patch on that page.

Utilization

Any script, command line tool, web mapping, desktop application that at one point knows what file format and what driver to use will be able to take advantage of that mechanism, ex.:

gdalinfo ingr:uint32.cot

Backward Compatibility Issues

That optional entry on GDALOpen process should not affect the current logic.

Testing

• Extra tests would be added to the test script
• The current test should succeed
• Test the impact in VRT files and gdalwarp options

Issues

But it is important to note that some drivers already accept a "driver-name:" entry and knows how to deal with it directly. In that case if the driver name entered is exactly the name of a driver then it will take advantage of the proposed mechanism avoiding the probing mechanism. Therefor entries like "GTIFF_RAW:xxx", "GEOR:xxx", "JPEG_SUBFILE:xxx" will fail to be loaded direct by any driver, since they are not real driver names. The control will be passed to the driver probing loop that will eventually open the file.