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