/*! \page ogr_arch
Because OGR is modelled on the OpenGIS simple features data model, it is very helpful to review the SFCOM, or other simple features interface specifications which can be retrieved from the Open GIS Consortium web site. Data types, and method names are modelled on those from the interface specifications.
Additional intermediate abstract base classes contain functionality that could eventually be implemented by other geometry types. These include OGRCurve (base class for OGRLineString) and OGRSurface (base class for OGRPolygon). Some intermediate interfaces modelled in the simple features abstract model and SFCOM are not modelled in OGR at this time. In most cases the methods are aggregated into other classes. This may change.
The OGRGeometryFactory is used to convert well known text, and well known binary format data into geometries. These are predefined ascii and binary formats for representing all the types of simple features geometries.
In a manner based on the geometry object in SFCOM, the OGRGeometry includes a reference to an OGRSpatialReference object, defining the spatial reference system of that geometry. This is normally a reference to a shared spatial reference object with reference counting for each of the OGRGeometry objects using it.
Many of the spatial analysis methods (such as computing overlaps and so forth) are not implemented at this time for OGRGeometry.
While it is theoretically possible to derive other or more specific geometry classes from the existing OGRGeometry classes, this isn't as aspect that has been well thought out. In particular, it would be possible to create specialized classes using the OGRGeometryFactory without modifying it.
The SRS definitions in the simple features specification are only half baked, and so many ambiguitites exist in how it should be implemented and used interoperabily. At this time the OGRSpatialReference object is only used to translate between SRS well known text format, and an queriable internal representation. In particular, no attempt has been made yet to validate the parameter values, or to provide reprojection and datum shifting capabilities.
There is a recently issued OpenGIS RFP intended to result in a coordinate transformations interface specification that would superceed the existing simple features SRS definitions; however, in a mostly backward compatible manner.
The set of attributes, their types, names and so forth is represented via the OGRFeatureDefn class. One OGRFeatureDefn normally exists for a layer of features. The same definition is shared in a reference counted manner by the feature of that type (or feature class).
The feature class also contains an indicator of the types of geometry allowed for that feature class (returned as an OGRwkbGeometryType from OGRFeatureDefn::GetGeomType()). If this is wkbUnknown then any type of geometry is allowed. This implies that features in a given layer can potentially be of different geometry types though they will always share a common attribute schema.
The OGRFeatureDefn also contains a concept of default spatial reference system for all features of that type and a feature class name (normally used as a layer name).
The OGRLayer includes methods for sequential and random reading and writing. Read access (via the OGRLayer::GetNextFeature() method) normally reads all features, one at a time sequentially; however, it can be limited to return features intersecting a particular geographic region by installing a spatial filter on the OGRLayer (via the OGRLayer::SetSpatialFilter() method).
One flaw in the current OGR architecture is that the spatial filter is set directly on the OGRLayer which is intended to be the only representative of a given layer in a data source. This means it isn't possible to have multiple read operations active at one time with different spatial filters on each. This aspect may be revised in the future to introduct an OGRLayerView class or something similar.
Another question that might arise is why the OGRLayer and OGRFeatureDefn classes are distinct. An OGRLayer always has a one-to-one relationship to an OGRFeatureDefn, so why not amalgamate the classes. There are two reasons:
OGRDataSource is an abstract base class. An implementation is expected to be subclassed for each file format driver implemented. OGRDataSource objects are not normally instantiated directly but rather with the assistance of an OGRSFDriver. Deleting an OGRDataSource closes access to the underlying persistent data source, but does not normally result in deletion of that file.
An OGRDataSource has a name (usually a filename) that can be used to reopen the data source with an OGRSFDriver.
It is intended that a new OGRSFDriver derived class be implemented for each file format to be supported (along with a file format specific OGRDataSource, and OGRLayer classes).
On application startup registration functions are normally called for each desired file format. These functions instantiate the appropriate OGRSFDriver objects, and register them with the OGRSFDriverRegistrar. When a data source is to be opened, the registrar will normally try each OGRSFDriver in turn, until one succeeds, returning an OGRDataSource object.
It is not intended that the OGRSFDriverRegistrar be derived from.
*/