Gdal source code analysis (1)

I have been using and studying gdal-related things and found that there are many gdal contents on the Internet, but there are few systematic introductions and some internal structure descriptions. Based on these reasons, put some of my superficial understandings here to form a series named "gdal source code analysis" (the name is a bit unpretentious. You are welcome to spit it out ), for your reference, if you have any errors, I hope you will not be able to correct them. gdal is used in this series on Windows platforms, and Linux platforms are not covered in this series. In addition, to repost the content of this blog, please indicate the source, and strongly despise the "Plagiarism" that does not indicate the source after reprinting.

1. Introduction to gdal

Gdal official website Region.

Before starting the article, I would like to raise a few questions: What is gdal? What can gdal do? How to Use gdal? How is the internal structure of gdal organized? What is the principle of the algorithm provided by gdal? For the above questions, I hope you will have less questions after reading this series of articles, and hope you will be helpful to the children's shoes you are interested in. I am not talented, and there will inevitably be problems in the article. I hope you will not correct me.

What is gdal? This is a simple question. In general, gdal is an open-source library for reading and writing space data (the space data here includes grid data and vector data) (but not limited to this, in addition, some commonly used algorithms and tools are provided ). Strictly speaking, you can refer to the introduction on the gdal homepage.

Gdal is a translator library for raster geospatial dataformats that is released under an X/MIT style open
Source license by the open source geospatial Foundation. As alibrary, it presents a singleabstract data model to the calling application for allsupported formats. it
Also comes with a variety of usefulcommandline utilities fordata translation and processing. thenewspage describes the July 2011 gdal/OGR 1.8.1
Release.

The related OGR Library (which lives within the gdal source tree) provides a similar capability forsimple features vector data.

Ii. gdal directory structure

First, we will give a brief introduction to the directory structure of gdal. Source code: gdal.

If the downloaded compressed package is used, its directory structure is as follows:

Figure 1 directory structure of gdal source code compressed package

If the source code downloaded using SVN is used, the directory structure is as follows:

Figure 2 gdal SVN source code file directory structure

The preceding two figures show that the directory structure of gdal is the same no matter how the source code is obtained, the following is a simple description of each folder and file in the directory structure. (In alphabetical order)

The following describes the folders:

1. ALG Folder: The ALG folder stores the source code of some algorithms provided in the gdal library. These algorithms include but are not limited to: DEM generation contour algorithm; Image Correction Algorithm (geometric correction, TPS correction, positive RPC correction), raster vectoring algorithm, vector raster algorithm, grid calculation algorithm, PCT and RGB conversion algorithm, and small fragmentation algorithm of classification chart.

2. Apps Folder: The apps folder stores the source code of some command line tool sets provided by the gdal library. For more information about these tool sets, see http://gdal.org/gdal_utilities.html. I will give a simple description of these tools. Some of these tools are very useful, such as gdalinfo, which can be used to view the metadata information of images.

3. Bridge Folder: The Bridge folder stores the definition of the gdal abstract class and the source code for the definition and implementation of the gdal struct. This folder will be described in detail when it comes to the implementation principle of gdal.

4. Data Folder: The data folder stores some "configuration files" that need to be used in the gdal Library (the configuration files may not be accurate here ), these files mainly include ESRI projection files, espg projection files, PCI projection and elliptical objects, AutoCAD header files, and other files. In the gdal library, files in the folder are automatically read. Generally, the folder is searched through environment variables. The environment variable name is gdal_data, and the value is the path of the data folder, alternatively, you can use the cplsetconfigoption ("gdal_data", "C: \ gdal \ data"); function in your program to set the directory of the folder, if gdal is not set, it is automatically searched from the environment variable. If gdal is not found, an error may be prompted. For example, if gdal_data is not set, in this case, the creation is not successful when writing the DXF format such as atuocad. We will explain it later.

5. Doc Folder: the doc folder is used to generate some documents of the gdal help document. The doc file is generated using the doxygen tool, the doxygen tool will be briefly introduced and described later, as well as how to use doxygen to generate development help documents for your own programs in your own project. In a word, this folder is used to generate the help document of the gdal library. The following will show you how to generate a gdal help document. Of course, you can also capture the entire website of gdal.org.

6. frmts Folder: this folder is the most frequently used folder in gdal code. Each time you update the gdal version, you will find several more folders in this folder, at the same time, gdal will also support several new file formats. Yes, this folder stores the source code parsed by gdal for each specific image format. For example, the BMP folder is used to parse BMP images, the HFA folder is used to parse the IMG image format of ERDAS, the raw folder is used to read the HDR file of ENVI, And the pcidsk folder is used to read the PIX format of PCI. Therefore, this folder stores the source code for parsing various file formats.

7. gcore Folder: You should also know what this folder is done by name. Core is definitely a very core thing, and this folder is the soul of gdal, the datasets, bands, and image read/write interfaces of the gdal abstract class are all implemented in this section. If you want to know how the abstract class of gdal abstracts the image format, you can look at the code in it.

8. html Folder: If the HTML folder uses a compressed package, it should be empty. This folder is mainly used to store the help document generated by gdal, the following describes how to use the doc script. The gdal help document generated by the doxygen tool is displayed in this folder. A detailed introduction will be provided later with the doc folder.

9. M4 Folder: The M4 folder contains several files suffixed with M4. The M4 file is called macroprocessor library, and the M4 file is the most core file in the compilation Foundation, this file mainly uses Autoconf to generate the configure configuration file and then automatically generate the MAKEFILE file. The Windows platform in this folder does not seem to have any effect. Maybe I still don't know it. I skipped it here.

10. Man Folder: The man folder seems to be used to generate help files for Linux or other platforms. It is estimated that man help files for Linux can be used. It seems that Windows is useless.

11. OGR Folder: If you have used gdal, you must know the OGR library. A long time ago, gdal and OGR were two libraries, and gdal was responsible for reading raster data, the OGR library is responsible for reading vector data. It may be because it is inconvenient to separate the two databases. For example, the gdal algorithm library often uses Vector Data Reading, or there are other reasons, these two databases are now integrated. Currently, the OGR database is a subset of the gdal database. In fact, the OGR library can still be compiled separately. The OGR folder is the folder that stores the source code of the OGR library. This folder also contains many things, which will be detailed later.

12. Port Folder: the port folder stores the port library. The port library is an underlying support library for the gdal library, and the port library defines some string operations, basic functions such as file processing, webpage requests, database connections, hash tables, and character Encryption File compression. For example, all the export function symbols in gdal, cpl_dll, are defined in this port folder. In the frmts folder, open files, open databases, open network paths, and so on, are all port libraries, and string processing.

13. swig Folder: The swig folder mainly stores swig scripts. The full name of swig is simplifiedwrapper and interface generator. The website is www.swig.org,
Swig is used to encapsulate a library written in C/C ++ as an access interface for python, C #, Java, Perl, Ruby, and other languages. The C # version of gdal on the internet is compiled and implemented using swig. It is very powerful. I will write an article about swig compiling gdal if I have time later.

14. VB6 Folder: Upload. Due to my use of VB6, I still only need to drag a button and write a foundation for clicking an event. I really don't understand the call between modules, the location is not described. If you want to use gdal with VB6, you can study it by yourself. It should not be difficult.

15. wince Folder: as the name suggests, the content in this folder is used to compile the gdal library on the Windows CE platform. For details about the compilation, see the instructions.

After the introduction of the folder is complete, a rough description of the file is given below:

1. aclocal. M4: Same as the M4 folder above

2. autogen. sh: The shell file on the Linux platform. It is used to call Autoconf to generate the configure configuration file.

3. commiters: The content in this file is the gdal developer's information, name, contact email address, and description of the modules in charge of development.

4. config. Guess, config. sub, configure, and configure. In: these four files are all configuration files on the Linux platform. They are useless in windows and skipped.

5. doxyfile: doxyfile is the doxygen project file mentioned in the preceding Doc folder. It is used to generate help documents. This file will be described later in the introduction of doxygen.

6. gdalmake. Opt. In: this file is the gdal library compilation configuration file on the Linux platform. The function is described in nmake. Opt later.

7. gdalnightlysvn. sh: A shell script that calls SVN on the Linux platform to obtain the gdal source code.

8. gnumakefile: GNU make file.

9. HOWTO-RELEASE: some descriptions of gdal release.

10. Install-SH: the installation shell script of gdal, on the Linux platform.

11. License. txt: license document for gdal.

12. ltmain. sh: libtool shell script. It seems useless in Windows on Linux.

13. makefile. VC: gdal compilation file, which is used to compile the source code into a DLL file, which will be introduced later in gdal compilation.

14. makegdal_gen.bat: a batch processing file used to generate the vs project file. The usage of this file will be described later in gdal compilation.

15. makegdal10.sln: All sln files in the folder are vs project files. The number after the file name indicates the version number of.

16. The project files makegdal10.vcxproj and makegdal71.vcproj: VS can be automatically generated by the makegdal_gen.bat file, which will be detailed later.

17. mkbindist. Sh, mkgdaldist. Sh, and mktestdist. sh: three shell script files, which are useless in windows and skipped.

18. News: New Features of gdal and bug fixes.

19. nmake. Opt: configuration file of gdal compilation options. In gdal compilation, you can specify other libraries bound to gdal to be set in this file. Detailed descriptions will be provided in the subsequent gdal compilation.

20, nmake-wince.opt: Compile the wince version of the compilation option configuration file.

21. provenance. txt: gdal directory description file. If the description above is not clear enough, refer to this file.

22. submake. BAT: A compiled batch file, which is useless currently.

23. svnkeywords. sh: it is also a shell script of SVN.

24. Version: gdal version information.

The first article is complete, and subsequent articles will be available soon. Please wait for a new one!