GDAL / OGR is not a single format but a collection of open source libraries that can read many formats, including many formats that Manifold can directly read using Manifold's own native dataports. This documentation uses the terms GDAL and GDAL / OGR interchangeably, since the two libraries are so closely related they are usually considered the same thing, and are simply called "GDAL."
To use GDAL or OGR we must install GDAL in Windows, as described below, and then we can use it from Manifold. If we do not install GDAL, we will not be able to use the capabilities described in this topic. The Manifold GDAL dataport allows working with versions from GDAL 2.0.x onward, and automatically selects the latest version available with automatic adjustments for the call interface. See the Third Party Release Levels topic for the latest GDAL / OGR version supported.
Important: GDAL / OGR is not a Manifold product. It is an "open source" product that may be downloaded and used for free.
Manifold tech support does not support GDAL: Manifold simply provides a dataport that makes it easier to utilize GDAL from within Manifold. For support on GDAL, we should use Google or other search engine to find forums in which users support each other, or we should hire a consultant specializing in GDAL support.
Manifold has the built-in ability to connect to, link, import and read/write to hundreds of different databases, file databases, file formats, web servers and similar data sources using Manifold's own internal code, with no need to install any additional software. Manifold's built-in dataports do not in any way depend upon GDAL. Many GIS products require installation of GDAL for import functionality, but Manifold does not.
In addition to Manifold's own, built-in import capabilities, Manifold also includes a dataport that can launch the GDAL/OGR libraries to connect to any format those libraries support. The use of GDAL / OGR is an optional extra for those users who would like to try GDAL.
Both the Manifold collection of data sources and the GDAL/OGR libraries collection of file formats are large collections so there is considerable overlap between the two. In many cases there is a native Manifold dataport for a data source and there is also a module available in the GDAL/OGR collections for that format. However, there are also data sources which Manifold supports that GDAL/OGR does not, and there are formats available within GDAL/OGR that Manifold does not include as a built-in to Manifold.
If we want to import data from a format that Manifold does not support but which is available within GDAL/OGR, we can use the Manifold GDAL dataport to connect through GDAL/OGR to the desired format. While that will have limitations compared to using a native Manifold connection, as discussed below, using GDAL may be the only way to get data out of a format that is not otherwise supported by Manifold.
Benefits: Using GDAL/OGR has many benefits, compared to a native Manifold dataport:
GDAL/OGR may support rare or nearly-extinct formats, such as the old ESRI GDB format that was replaced by modern ESRI GDB format, which are not supported by Manifold.
Manifold dataports for some formats, especially rarely used ones, may contain bugs. One way to get around those bugs might be to try the equivalent GDAL/OGR format, which may perform more reliably. GDAL also has bugs, but it is unlikely that GDAL bugs would be the same as Manifold bugs. Using one or the other option can therefore dodge problems where a bug in Manifold or in GDAL might be an issue.
Some formats are ambiguously defined and data sets may vary as to how they interpret the requirements of ambiguous formats. In such cases, different authors and different software packages may import the same data in different ways. It can be very convenient in such cases to see what Manifold does for an import and what GDAL/OGR does, and then choose which version is preferred.
Manifold may apply standards and format definitions more rigorously in some cases than GDAL/OGR. Sometimes that may lead to Manifold rejecting a data set that GDAL/OGR allows.
Packages that import data from many different formats will often differ in the results they produce, with every package having its quirks. Users who are very familiar with GDAL may simply prefer the GDAL quirks they already know to learning a new set of quirks within Manifold.
Limitations: Using GDAL/OGR from Manifold also has limitations, compared to a native Manifold dataport:
GDAL/OGR must be downloaded and installed. It is not built into Manifold.
GDAL/OGR binaries are provided not by gdal.org but by third parties, who may have their own opinions what the product should be.
GDAL/OGR code in the past has changed in ways that are incompatible with prior GDAL/OGR releases. The Manifold GDAL dataport allows working with versions from GDAL 2.0.x onward, up to the currently supported GDAL version, and automatically selects the latest version available with automatic adjustments for the call interface. See the Third Party Release Levels topic for the latest GDAL / OGR version supported.
Connections through GDAL/OGR are read-only and are not read/write the way Manifold native connections usually are.
GDAL/OGR connections in general are not parallel code, that is, they are not thread-safe, so they cannot run parallel and thus may perform more slowly.
GDAL/OGR code is open source, in part written by unknown persons, and is neither supported nor guaranteed by the authors.
GDAL/OGR functionality for some formats may require libraries or other code from other third parties, including commercial enterprises, some of which may require agreement to additional licenses, restrictions of rights, or other limitations.
GDAL/OGR code often depends in turn upon other libraries, which may change in unexpected ways.
GDAL/OGR code is not supported nor endorsed by Manifold.
For a real life discussion on GDAL use in GIS, see the example topics, such as the Example: Connect to Manifold from QGIS topic,
To use GDAL/OGR the Manifold GDAL dataport requires installation on our machine of the GDAL/OGR libraries, plus any optional GDAL/OGR modules we want to use. Manifold is happy to work with third party software like GDAL/OGR but Manifold by default does not automatically install that third party software. Testing shows the biggest problem users have with GDAL/OGR is getting GDAL installed on their machine, and with updating the Windows PATH environmental variable to correctly point at the GDAL installation.
Visit gdal.org for information on obtaining the GDAL/OGR installation packages for Windows. Gdal.org does not provide binary installation packages for Windows but the site does provide links to third party sites which have created GDAL products of various kinds using source code.
This example uses installation packages downloaded from the GISInternals.com site, a third party site that has no connection to Manifold. Manifold makes no guarantees these are safe to use or do not contain malware. The GISInternals.com site does not provide SHA codes to verify integrity of the download. Users who are concerned about downloading and installing unverified binaries from third party sites should study the gdal.org site to learn how to obtain source code for GDAL/OGR. Users can then apply their own software development skills to create their own Windows installation packages.
The objective is to get a set of .msi Windows Installer packages like the above. Get whatever is the latest GDAL package that the Third Party Release Levels topic says is supported. That might be in the archived versions section of the GISInternals.com site
In most cases there will be several installation packages, usually one for most GDAL/OGR capabilities plus additional modules that GDAL calls "plugins," that is, optional modules, which usually provide code based on SDKs or other code licensed from third parties. For example, based on their names the modules seen above appear to provide code for ECW format reading that seems to derive from the Hexagon Geospatial SDK, file database GDB reading code from ESRI, MrSID reading code from Lizardtech, and software from Oracle. Such optional modules normally require agreement to the license terms set forth by their owners, which at times are radically different licenses.
For the purposes of this topic, the core package seen above was installed into a folder called C:\Program Files\GDAL. All of the other modules were then installed giving the same folder location for installation.
After installation, in Windows Explorer we see that many files were installed into that folder, including some .dll files at the folder root.
In addition, many other .dll files were installed in the gdalplugins sub-folder.
For GDAL/OGR to be usable by other programs, such as Manifold, the locations of necessary .dll files must be part of the system PATH environment variable. The PATH variable tells Windows where to look for executables. This example shows Windows 10.
To add the installation folders for our GDAL .dll files to the PATH we launch the System applet in the Windows Control Pane. Click on Advanced system settings.
In the resultant System Properties dialog click on Environmental Variables.
In the System variables pane of the resultant dialog, click on Path to highlight that entry and choose Edit.
Click New and then add C:\Program Files\GDAL and then click New again and add C:\Program Files\GDAL\gdalplugins. These are the two folders in which .dll files appeared when we installed the GDAL/OGR packages specifying as an installation folder the C:\Program Files\GDAL folder. Of course, if we chose different folders when we installed the GDAL/OGR packages we would specify those different folders. Press OK.
Do we really need to add both folders to the PATH? We do not know and do not need to care. It is easier to simply add both than to try to puzzle out how GDAL works and what is necessary and what is not.
Once GDAL has been installed, using the GDAL dataport within Manifold is easy. Launch Manifold and choose File - Import.
Navigate to the folder where the files of interest are located. In the files of type box we simply choose .Files (GDAL/OGR) (*.*). We can then click on whatever file we want to import and that import will be done through the GDAL dataport. Easy!
For example, if we want to import an ERDAS file in .gis format through GDAL, we first choose .Files (GDAL/OGR) (*.*), we click on the .gis file desired to load it into the File name box, and then we press the Import button. Done!
If nothing appears when importing using GDAL, launch the Log Window to see if there are any error messages. For example, when importing an ESRI .e00 file fails, in the Log Window you might see an error message such as:
*** (import) This looks like a compressed E00 file and cannot be processed directly. You may need to uncompress it first using the E00compr library or the e00conv program.
Error messages in the Log Window might report other problems, such as the necessary GDAL .dll files not being found. That usually happens when the PATH environment variable does not include the GDAL installation folders. See the discussion earlier in this topic on setting the PATH environment variable.
What does GDAL stand for? GDAL - Geospatial Data Abstraction Library.
What does OGR stand for? OGR. OGR is not a direct acronym but a strange, three letter word of its own. According to a FAQ apparently written by the author of OGR, "OGR used to stand for OpenGIS Simple Features Reference Implementation. However, since OGR is not fully compliant with the OpenGIS Simple Feature specification and is not approved as a reference implementation of the spec the name was changed to OGR Simple Features Library. The only meaning of OGR in this name is historical."
What is the relationship between GDAL and OGR? In a nutshell, OGR is a vector library while GDAL is a raster library. From the FAQ: OGR is "a vector IO library inspired by OpenGIS Simple Features" the source code to which is "somewhat entangled" with GDAL sources. As a practical matter, virtually everyone refers to both as simply "GDAL."
GDAL is not Manifold - When connecting to GDB using GDAL/OGR we must be aware we are no longer using Manifold code but instead are using GDAL code. GDAL has earned a good reputation. It is a tremendous advantage to use GDAL's very broad reach of modules from Manifold to connect to many niche or nearly-extinct formats, and GDAL does a great job at that. However, GDAL's code in general is not as bulletproof as the Radian technology used in Manifold. Connections using GDAL fall outside of Manifold's reputation for never crashing.
Example: Create a Table and Add a Record - Create a table with required fields and then add a record with value for those fields. Creates the OGR-required table to prepare a Manifold project for use by OGR as detailed in this topic.
Example: Create an ODBC Data Source with Windows - How to create an ODBC data source (a DSN) using dialogs built into Windows 10.
Example: Connect to Manifold from Release 8 - Step by step procedure to connect from Manifold System Release 8 to a Manifold .map file using Manifold's ODBC driver.
Example: Connect to an ESRI GDB File Geodatabase - Connect Manifold to an ESRI GDB file geodatabase, display the contents, make a selection in the GDB and overlay in a map.
Example: Import ERDAS GIS with GDAL and Assign Coordinate System - A multistep example that covers import of an unwieldy format using GDAL, followed by use of Assign Initial Coordinate System and Repair Initial Coordinate System to deal quickly with real-life complications.
Example: Connect to an ESRI GDB usng GDAL/OGR - Instead of using Manifold's built-in ability to connect to modern ESRI GDB file geodatabases, use the Manifold GDAL/OGR dataport to take advantage of the GDAL library's ability to connect to deprecated GDB formats.
Example: Connect Through Manifold ODBC to a Third Party - With Release 8, use an ODBC connection to a Manifold .map to connect through the .map project to a third party, external data source, an ESRI GDB file geodatabase. We use Manifold facilities as an intermediary to give Release 8 capabilities it does not have on its own, to link into data stored within an ESRI file geodatabase.
Example: Connect LibreOffice Through Manifold to an ESRI GDB - A companion example topic to the Example: Connect Through Manifold ODBC to a Third Party topic. Shows how to connect LibreOffice Base, the database part of LIbreOffice, through Manifold to link an ESRI GDB file geodatabase table into LibreOffice.
Example: Connect to Manifold from QGIS - Step by step procedure to connect from QGIS 2.8.9 to a Manifold .map file using Manifold's ODBC driver.