Changes between Initial Version and Version 1 of rfc36_open_by_drivername

Timestamp:

Sep 30, 2011, 6:30:09 AM (13 years ago)

Author:

ilucena

Comment:

--

rfc36_open_by_drivername

@@ +1 @@
+= RFC 36: Allow specification of intended driver on GDALOpen =
+
+Authors: Ivan Lucena[[BR]]
+Contact: ivan.lucena@pmldnet.com[[BR]]
+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, ex.:
+
+{{{
+gdalinfo georaster:mike/bear@dbg,arch,img,id=123
+}}}
+
+So entries like "GTIFF_RAW:", "GEOR:", "JPEG_SUBFILE:" will fail to be loaded direct by any driver, since they are not real drivers names, and in that case the datasets will be opened by the existing driver probing mechanism.
+