1.. _rfc-27: 2 3================================================================================ 4RFC 27: Improved Supporting Data File Options 5================================================================================ 6 7Author: Frank Warmerdam 8 9Contact: warmerdam@pobox.com 10 11Status: Development 12 13Summary 14------- 15 16Currently GDAL depends on a variety of supporting data files from the 17`gdal data <http://svn.osgeo.org/gdal/trunk/gdal/data>`__ directory. The 18largest part of these are coordinate system dictionaries from EPSG and 19other sources. It also includes S-57 dictionaries, seed DGN and DXF 20files, and project logos. Uncompressed it currently comes to roughly 211.8MB and it is expected to grow as additional dictionaries are added 22(for PCI and IAU coordinate systems for instance). 23 24It has also been a frequent problem at run time to find the data files 25when they are installed in unusual locations. 26 27This RFC aims to overhaul support file handling with two new major 28features. 29 301. The ability to read from compressed data files to reduce the disk 31 footprint of GDAL. 322. The ability to embed the data files with the GDAL DLL or shared 33 library to remove the "finding" problem. 34 35CPL CSV Access via VSI*L 36------------------------ 37 38The large majority of the support data file access is via the CPL CSV 39API (gdal/port/cpl_csv.cpp). Finding support data files is done via 40CPLFindFile(). It turns out these functions are still using the old VSI 41API which does not support special handlers (like /vsizip/), or in at 42least one case direct fopen() calls. So the first stage of this RFC is 43to convert these functions to all use the VSI*L API. A 44`patch <http://trac.osgeo.org/gdal/attachment/wiki/rfc27_supportdata/rfc27_csv_vsil.patch>`__ 45has been prepared that demonstrates the bulk of the required changes. 46With this patch it is possible to access files from a GDAL_DATA setting 47like /vsizip//home/warmerda/gdal/data/gdaldata.zip. 48 49Note that we are explicitly changing the contract about the nature of 50the FILE\* passed to functions like CSVReadParseLine() (real FILE\* vs. 51VSI\ *L style FILE*). It is possible, though relatively unlikely that 52application code, or private driver implementations will be using the SV 53functions and will need to be changed. This change should be noted in 54the GDAL 1.8 release notes. 55 56It is also unclear if there will be bad interactions with the cpl_csv 57implementation embedded in libgeotiff in some situations, such as when 58using libgeotiff as an external library. Some review will be needed. 59 60Another point to investigate is what the performance impact of doing all 61the file finding through the VSI*L API will be. 62