Changes between Version 3 and Version 4 of rfc36_open_by_drivername

Timestamp:

Oct 5, 2011, 9:15:57 PM (13 years ago)

Author:

ilucena

Comment:

--

rfc36_open_by_drivername

@@ -11 +11 @@
 == 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.
+By selecting the driver, users can optimize processing time and avoid incorrect or undesirable driver selection due to the driver probing mechanism.
 
 == 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". 
+The idea is to pass to GDALOpen a string containing the token "driver=" followed by the driver name and a comma separating it from the file-name.
 
+[driver=driver-name,]file-name
+
+Examples:
+
+$ gdalinfo driver=nitf:imagefile01.ntf
+
+In that case no probing is necessary, since the user has indicated to use the specific driver. If for some reason that process fails the function returns NULL and no other attempt is made to open the file by another driver.
+ 
 == 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.
+The amount of code is minimal and there is already a proposed patch on ticket #3043.
 
 == 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
-}}}
+Any application that uses GDAL API or any GDAL command line tool's user that, at one point, wants to force the use of a particular driver to open a datasets.
 
 == Backward Compatibility Issues ==
 
-That optional entry on GDALOpen process should not affect the current logic. 
+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.
-
+For gdalbuildvrt and gdaltindex it will not be possible to use the driver selection with wildcard, as in "driver=gtiff,*.tif".