Plug-in data sources

---

A plug-in data source integrates a new data format completely into ArcGIS as read-only. The data source can be browsed, previewed, and managed in ArcCatalog. Its data can be selected, rendered, queried, labeled, and joined in ArcMap. The data source can also be accessed using normal geodatabase interfaces, such as IWorkspace and IFeatureClass. See the following screen shot:

The following are some limitations to plug-in data sources - only tables, feature classes, and feature datasets are supported. Plug-in data sources cannot be integrated with geodatabase objects, such as relationship classes and geometric networks. Also, only simple feature types - points, lines, and polygons - are supported. For example, plug-in data sources for annotation or dimension features cannot be implemented.

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 Open Geodata Interoperability Specification (OGIS)-compliant Object Linking and Embedding (OLE) database provider. The comparison of custom data source implementations table in this topic analyzes the relative merits of different solutions for custom data.

The plug-in data source mechanism can support many kinds of data. It is useful to categorize them into the following three types:

To understand different kinds of data sources, it is important to note the distinction between a dataset and a workspace. A dataset can be a table, 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 might be multiple datasets in a single folder. The folder is considered 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, such as .prj, .sbn, .sbx, and .shp.xml (ArcGIS software-generated metadata). Therefore, 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 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 so on. The folder that contains this folder might have many coverages and has a folder (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 the Vector Product Format (VPF).

In a database data source, a workspace is a file or group of files, or might not be 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 might 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 Transmission Control Protocol/Internet Protocol (TCP/IP).

The following table compares custom data source implementations:

Data source	Advantages	Disadvantages
Custom layers	Fairly simple to get a basic implementation working. Performance can be optimized as there are few restrictions on implementation details. Data can remain encrypted - the end user can be limited to graphical user interface (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 a custom layer as fully functional as a standard FeatureLayer. Not all ArcGIS tools work with a custom layer unless every FeatureLayer interface is implemented; therefore, custom tools are generally required to work with a custom 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.	Read-only. Significant amount of development required.
OGIS-compliant OLE database providers	Read-writable (if implemented that way). Generic, open solution - works in applications not based on ArcGIS.	Significant amount of development required; more to make it writable. 2D data only.