About Plug-In Data Sources

ArcGIS deals with several read-only data sources such as StreetMap, CAD, and the SDC format used by RouteMap IMS.

The method by which ArcGIS handles some of these data sources has been exposed to developers. You can provide ArcGIS support for your own data formats by implementing a plug-in data source.

A plug-in data source integrates a new data format completely into ArcGIS, albeit in a read-only manner. You can browse, preview, and manage the data in ArcCatalog. You can select, render, query, label, and join the data in ArcMap. You can also program with the data source using normal geodatabase interfaces such as IWorkspace and IFeatureClass.

There are some limitations: only tables, feature classes, and feature datasets are supported; you cannot integrate plug-in data sources with geodatabase objects such as relationship classes and geometric networks. Also, only simple feature types (points, lines and polygons) are supported—for example, you cannot implement plug-in data sources for annotation or dimension features.

There are two main alternatives to a plug-in data source. The first is to implement a custom layer; the other alternative is to implement an OGIS-compliant OLE DB provider. Both these solutions have their own sections in this book. The comparison of custom data source implementations table in this topic analyzes the relative merits of these different solutions for custom data.

The plug-in data source mechanism can support many kinds of data. It is useful to categorize them into three types: file-based, folder-based, and database data sources.

To understand different kinds of data sources, it is important to note the distinction between a dataset and a workspace. A dataset may be a table, a feature class (table with geometry), or a feature dataset (a collection of feature classes that share the same spatial reference). A workspace is a collection of datasets in the same location.

In a file-based data source, a dataset is a file or group of files, named such that there may be multiple datasets in a single folder. The folder is considered to be the workspace. If a dataset has several files, the files usually have the same base name with different extensions. For example, a shapefile is a collection of files that have the same base name and several extensions, in particular .dbf, .shp, and .shx, as well as optional files like .prj, .sbn, .sbx, and .shp.xml' (ArcGIS software-generated metadata). So a collection of files named streets.dbf, streets.shp, and streets.shx are together a single shapefile named 'streets'. Another example of a file-based data source is CAD.

In a folder-based data source a dataset is a file or group of files, named such that there can be only one dataset in a folder. The workspace is considered to be the folder that contains the dataset folder. The files usually have the same names for every dataset, and the name of the folder is the name of the dataset. For example, a coverage consists of a folder whose name is the name of the dataset. This folder contains files such as aat.adf, arc.adf, arx.adf, bnd.adf, tic.adf, and others. The folder that contains this folder may have many coverages and has a folder called 'info' that has information about all coverages in that workspace. A coverage is also an example of a feature dataset. Another example of a folder-based data source is VPF.

In a database data source, a workspace is a file or group of files or is not a file at all, but is specified by a workspace string only. It is generally possible to have several of these workspaces in a single folder. For example, with an Access personal geodatabase, a workspace is a single file with a .mdb extension whose base name is the name of the database. The database can contain multiple datasets. ArcSDE workspaces have no necessary files, though they may be represented in the file system as a connection file that has a connection string. The connection string specifies how to access the data over TCP/IP.

This table compares the merits of different solutions for integrating custom data sources with ArcGIS.

	Advantages	Disadvantages
Custom layers	Fairly simple to get a basic implementation working.   Performance can be optimized as there are few restrictions on implementation details.   Can implement in VC++, VB.NET, and C#.   Data can remain encrypted—the end user can be limited to GUI access only.	Cannot be used to represent the data in ArcCatalog (though additional ArcCatalog customizations could be deployed in parallel).   Read-only (though custom tools for editing could be deployed in parallel).   Since there are so many interfaces to implement, it can be difficult to make your layer as fully functional as a standard FeatureLayer unless you use aggregation.   Not all ArcGIS tools will work with a custom layer unless you implement all the interfaces that the FeatureLayer class does; therefore, you generally need to build custom tools to work with your layer.
Plug-in data sources	Solution is integrated into ArcGIS (ArcMap, ArcCatalog, and so on).   Other developers can program against the data source with normal geodatabase ArcObjects.   Can implement in VC++, VB.NET, and C#.	Read-only.   Significant amount of development required.
OGIS-compliant OLE DB providers	Read-writable (if implemented that way).   Generic, open solution—works in non-ArcGIS applications.	Significant amount of development required. More to make it writable.   Only VC++ is realistic for implementation.   2D data only.