The naming conventions used in version 3.2 of the FDO API have been modified from those exposed in version 3.0. These modifications were undertaken to move the naming conventions used in the API away from its Autodesk roots and position itself within the OSGeo framework. As a result of implementing these changes, users will be required to modify their applications to use the names of the renamed FDO classes, enumerations, header files, libraries, etc.
NOTE: The API changes made moving from 3.0 and 3.2 are also applicable when discussing the differences between 3.1 and 3.2.
The following sections provide an overview on the naming changes that were made in FDO 3.2.
There was a subset of the FDO API that had not been implemented in any provider. These unimplemented interfaces were removed from the FDO API.
Removing the Topology API meant that all the topology related classes, files and enumeration values were removed from the FDO API.
A summary of the required changes are as follows:
· The FdoITopologyCapabilities interface was removed from the FDO API.
· The FdoIConnection interface was modified to remove the topology related capabilities method.
virtual FdoITopologyCapabilities* GetTopologyCapabilities();
· The FdoCommandType Enumeration was updated to remove the Topology related enumeration values.
FdoCommandType_ActivateTopologyArea
FdoCommandType_DeactivateTopologyArea
FdoCommandType_ActivateTopologyInCommandResult
FdoCommandType_DeactivateTopologyInCommandResults
· The following command interfaces were removed from the FDO API as well as their associated .h and .cpp files.
FdoIActivateTopologyArea
FdoIDeactivateTopologyArea
FdoIActivateTopologyInCommandResults
FdoIDeactivateTopologyInCommandResults
FdoIMoveTopoNode
FdoIReconnectTopoEdge
· The following schema management classes were removed from the FDO API as well as their associated .h and .cpp files.
FdoTopoGeometryPropertyDefinition
FdoTopology
Removing the Network API will mean that all the network related classes, files and enumeration values were removed from the FDO API.
A summary of the required changes are as follows:
· The FdoISchemaCapabilities interface was modified to remove the following network related capabilities method.
virtual bool SupportsNetworkModel();
· The FdoCommandType Enumeration was updated to remove the FDO Network related enumeration values.
FdoCommandType_NetworkShortestPath
FdoCommandType_NetworkAllPaths
FdoCommandType_NetworkReachableNodes
FdoCommandType_NetworkReachingNodes
FdoCommandType_NetworkNearestNeighbors
FdoCommandType_NetworkWithinCost
FdoCommandType_NetworkTSP
· The following command and reader interfaces were removed from the FDO API as well as their associated .h and .cpp files.
FdoINetworkCommand
FdoINetworkAllPathsCommand
FdoINetworkNearestNeighborsCommand
FdoINetworkPathReader
FdoINetworkReachableNodesCommand
FdoINetworkReachingNodesCommand
FdoINetworkReader
FdoINetworkShortestPathCommand
FdoINetworkTSPCommand
FdoINetworkWithinCostCommand
· The following enumeration values were removed from the FdoClassType enumeration.
FdoClassType_NetworkClass,
FdoClassType_NetworkLayerClass,
FdoClassType_NetworkNodeClass,
FdoClassType_NetworkLinkClass
· The following schema management classes were removed from the API as well as their associated .h and .cpp files.
FdoNetworkClass
FdoNetworkFeatureClass
FdoNetworkLayerClass
FdoNetworkLinkFeatureClass
FdoNetworkNodeFeatureClass
Components in the FDO API were renamed to remove references to Gis and to standardize the components to use FDO (uppercase) as a prefix.
|
Component |
Description |
|
GisCommon |
Common type definition and templates. Renamed to FDOCommon. |
|
GisGeometry |
Geometry interfaces and factory for FGF. Renamed to FDOGeometry |
|
FdoMessage |
Message catalogue for FDO. Renamed to FDOMessage |
|
GisMessage |
Message catalogue for GisCommon and GisGeometry Integrated with FDOMessage to form a single message catalogue. |
|
GisNLS |
Globalization utility Renamed to FDONLS |
|
GisSpatial |
Utility component around GisGeometry. Includes: geometry validation, transformation of ordinate (integer to double), approximation algorithm. Renamed to FDOSpatial. |
|
MgCommon |
Managed wrapper for GisCommon. Renamed to OSGeo.FDO.Common.dll |
|
MgFDO |
Managed wrapper for Fdo. Renamed to OSGeo.FDO.dll |
|
MgGeometry |
Managed wrapper for GisGeometry. Renamed to OSGeo.FDO.Geometry.dll |
|
MgSpatial |
Spatial utility based on GisGeometry. Renamed to OSGeo.FDO.Spatial.dll |
|
|
|
With these changes, all class names in the FDO API should now start with camel case “Fdo”. The FDO interface definitions will start with “FdoI”. Class members will be defined by getter and setter prefix with Get/Set.
The FDO providers implmentations have been 'somewhat' standardized to name their Fdo implementation classes following the pattern: Fdo<provider abbreviation>Implementation.
The current FDO API makes use of terms ‘Autodesk’ and ‘Gis’. These terms will be replaced in the Open Source release with ‘OSGeo’ and ‘Fdo’. The following sections outline the major areas of change.
In version 3.0 the namespaces for the FDO Managed APIs refer to Autodesk.Gis.Fdo. These namespaces will be modified to reference OSGeo.FDO as follows:
|
3.0 API |
3.2 API |
|
Autodesk.Gis |
OSGeo |
|
Autodesk.Gis.Runtime |
OSGeo.Runtime |
|
Autodesk.Gis.Common |
OSGeo.Common |
|
Autodesk.Gis.Geometry |
OSGeo.Geometry |
|
Autodesk.Gis.Spatial |
OSGeo.Spatial |
|
Autodesk.Gis.Fdo |
OSGeo.FDO |
|
Autodesk.Gis.Fdo.Utilities |
OSGeo.FDO.Utilities |
|
Autodesk.Gis.Fdo.Providers |
OSGeo.FDO.Providers |
|
Autodesk.Gis.Fdo.Providers.Shape |
OSGeo.FDO.Providers.SHP |
|
Autodesk.Gis.Fdo.Providers.ODBC |
OSGeo.FDO.Providers.ODBC |
|
Autodesk.Gis.Fdo.Providers.MySQL |
OSGeo.FDO.Providers.MySQL |
|
Autodesk.Gis.Fdo.Providers.WMS |
OSGeo.FDO.Providers.WMS |
|
Autodesk.Gis.Fdo.Providers.WFS |
OSGeo.FDO.Providers.WFS |
There are a number of FDO macro and preprocessor definitions that were renamed to remove references to Gis.
|
3.0 API |
3.2 API |
|
EXP_GIS |
EXP_FDO |
|
EXP_GISGEOM |
EXP_GEOM |
|
GIS_API |
FDO_API |
|
GISGEOM_API |
GEOM_API |
|
GISSPATIAL_STATIC |
SPATIAL_STATIC |
|
EXP_GISSPATIAL |
EXP_SPATIAL |
|
GISSPATIAL_API |
SPATIAL_API |
|
GIS_COLL_MAP_THRESHOLD |
FDO_COLL_MAP_THRESHOLD |
|
GIS_NLSID |
FDO_NLSID |
|
GIS_SAFE_RELEASE |
FDO_SAFE_RELEASE |
|
GIS_SAFE_ADDREF |
FDO_SAFE_ADDREF |
There were a number of FDO type definitions that were renamed to remove references to Gis.
|
3.0 API |
3.2 API |
|
GisDimensionality |
FdoDimensionality |
|
GisGeometryType |
FdoGeometryType |
|
GisGeometryComponentType |
FdoGeometryComponentType |
|
GisStreamReaderType |
FdoStreamReaderType |
|
GisSpatialGeometryValidity |
FdoSpatialGeometryValidity |
|
GisToken |
FdoToken |
|
gis_awkt_yytokentype |
fdo_awkt_yytokentype |
|
GisByte |
FdoByte |
|
GisInt8 |
FdoInt8 |
|
GisInt16 |
FdoInt16 |
|
GisInt32 |
FdoInt32 |
|
GisInt64 |
FdoInt64 |
|
GisCharacter |
FdoCharacter |
|
GisVoid |
FdoVoid |
|
GisDouble |
FdoDouble |
|
GisFloat |
FdoFloat |
|
GisSize |
FdoSize |
|
GisBoolean |
FdoBoolean |
|
GisString |
FdoString |
|
GisDateTime |
FdoDateTime |
|
GisSpatialGeometryValidity |
FdoSpatialGeometryValidity |
The prefix for the FDO Common classes was changed from Gis to Fdo
|
3.0 Class Names |
3.2 Class Names |
|
|
|
|
GisArray |
FdoArray |
|
GisIntArray |
FdoIntArray |
|
GisArrayHelper |
FdoArrayHelper |
|
GisCollection |
FdoCollection |
|
GisDictionary |
FdoDictionary |
|
GisDictionaryElement |
FdoDictionaryElement |
|
GisDisposable |
FdoDisposable |
|
GisIDisposable |
FdoIDisposable |
|
GisException |
FdoException |
|
GisPtr |
FdoPtr |
|
GisSemaphore |
FdoSemaphore |
|
GisStringP |
FdoStringP |
|
GisIDisposable |
FdoIDisposable |
|
GisIStreamReader |
FdoIStreamReader |
|
GisIStreamReaderTmpl |
FdoIStreamReaderTmpl |
|
GisNamedCollection |
FdoNamedCollection |
|
GisReadOnlyNamedCollection |
FdoReadOnlyNamedCollection |
|
GisRestrictedNamedCollection |
FdoRestrictedNamedCollection |
|
GisStack |
FdoStack |
|
GisStringElement |
FdoStringElement |
|
GisStringCollection |
FdoStringCollection |
|
GisStringsP |
FdoStringsP |
|
GisDateTime |
FdoDateTime |
|
GisVectorElement |
FdoVectorElement |
|
GisVector |
FdoVector |
|
GisVectorP |
FdoVectorP |
|
GisGml212 |
FdoGml212 |
|
GisGml212Schema |
FdoGml212Schema |
|
GisIoBufferStream |
FdoIoBufferStream |
|
GisIoByteStreamReader |
FdoIoByteStreamReader |
|
GisIoFileStream |
FdoIoFileStream |
|
GisIoMemoryStream |
FdoIoMemoryStream |
|
GisIoObjectStreamReader |
FdoIoObjectStreamReader |
|
GisIoObjectStream |
FdoIoObjectStream |
|
GisIoStream |
FdoIoStream |
|
GisIoTextReader |
FdoIoTextReader |
|
GisIoTextWriter |
FdoIoTextWriter |
|
GisXmlAttribute |
FdoXmlAttribute |
|
GisXmlAttributeCollection |
FdoXmlAttributeCollection |
|
GisXmlCharDataHandler |
FdoXmlCharDataHandler |
|
GisXmlCopyHandler |
FdoXmlCopyHandler |
|
GisXmlReader |
FdoXmlReader |
|
GisXmlSaxContext |
FdoXmlSaxContext |
|
GisXmlSaxHandler |
FdoXmlSaxHandler |
|
GisXmlSkipElementHandler |
FdoXmlSkipElementHandler |
|
GisXmlUtilXrcs |
FdoXmlUtilXrcs |
|
GisXmlWriter |
FdoXmlWriter |
|
GisXml |
FdoXml |
|
GisXslTransformer |
FdoXslTransformer |
|
GisXslTransformerXalan |
FdoXslTransformerXalan |
|
|
|
NOTE: Class GisException and class FdoException were merged together to form a single FdoException exception class.
The prefix of the FDO Geometry classes was changed from Gis to Fdo
|
3.0 Class Names |
3.2 Class Names |
|
|
|
|
GisDirectPositionImpl |
FdoDirectPositionImpl |
|
GisEnvelopeImpl |
FdoEnvelopeImpl |
|
GisGeometryFactoryAbstract |
FdoGeometryFactoryAbstract |
|
GisIArcSegmentAbstract |
FdoIArcSegmentAbstract |
|
GisICircularArcSegment |
FdoICircularArcSegment |
|
GisICurveAbstract |
FdoICurveAbstract |
|
GisICurvePolygon |
FdoICurvePolygon |
|
GisCurvePolygonCollection |
FdoCurvePolygonCollection |
|
GisICurveSegmentAbstract |
FdoICurveSegmentAbstract |
|
GisCurveSegmentCollection |
FdoCurveSegmentCollection |
|
GisICurveString |
FdoICurveString |
|
GisCurveStringCollection |
FdoCurveStringCollection |
|
GisIDirectPosition |
FdoIDirectPosition |
|
GisDirectPositionCollection |
FdoDirectPositionCollection |
|
GisIEnvelope |
FdoIEnvelope |
|
GisIGeometricAggregateAbstract |
FdoIGeometricAggregateAbstract |
|
GisIGeometry |
FdoIGeometry |
|
GisGeometryCollection |
FdoGeometryCollection |
|
GisILinearRing |
FdoILinearRing |
|
GisLinearRingCollection |
FdoLinearRingCollection |
|
GisILineString |
FdoILineString |
|
GisLineStringCollection |
FdoLineStringCollection |
|
GisILineStringSegment |
FdoILineStringSegment |
|
GisIMultiCurvePolygon |
FdoIMultiCurvePolygon |
|
GisIMultiCurveString |
FdoIMultiCurveString |
|
GisIMultiGeometry |
FdoIMultiGeometry |
|
GisIMultiLineString |
FdoIMultiLineString |
|
GisIMultiPoint |
FdoIMultiPoint |
|
GisIMultiPolygon |
FdoIMultiPolygon |
|
GisIPoint |
FdoIPoint |
|
GisPointCollection |
FdoPointCollection |
|
GisIPolygon |
FdoIPolygon |
|
GisPolygonCollection |
FdoPolygonCollection |
|
GisIRing |
FdoIRing |
|
GisRingCollection |
FdoRingCollection |
|
GisIRingAbstract |
FdoIRingAbstract |
|
GisISurfaceAbstract |
FdoISurfaceAbstract |
|
GisAgfGeometryFactory |
FdoFgfGeometryFactory |
|
GisGeometryStreamFactory |
FdoGeometryStreamFactory |
|
GisGeometryStreamReader |
FdoGeometryStreamReader |
|
GisGeometryStreamWriter |
FdoGeometryStreamWriter |
|
|
|
The prefix of the FDO Spatial API classes was changed from Gis to Fdo
|
3.0 Class Name |
3.2 Class Name |
|
|
|
|
GisSpatialGridTransform |
FdoSpatialGridTransform |
|
GisSpatialUtility |
FdoSpatialUtility |
|
|
|
The FDO API used the term AGF or Autodesk Geometry Format in version 3.0 of it’s API. In version 3.2 This term will be replaced with FGF which shall represent Fdo Geometry Format or Feature Geometry Format.
In order to make this change the geometry class that handles the creation of AGF geometry GisAgfGeometryFactory and GisAgfGeometryFactory2, will have to be renamed FdoFgfGeometryFactory and FdoFgfGeometryFactory2. There are also factory methods such as CreateGeometryFromAgf and GetAgf that will need to be modified.
|
3.0 Factory Method Name |
3.2 Factory Method Name |
|
|
|
|
CreateGeometryFromAgf |
CreateGeometryFromFgf |
|
GetAgf |
GetFgf |
|
|
|
Physical Overrides APIs are defined for the SHP, ODBC, MySQL and WMS providers. In 3.0, the naming conventions for the APIs had not been standardized. As a part of the Open Source preparedness effort, these APIs were standardized to use a common prefix of Fdo[Provider]Ov. This naming convention is already in use for the ODBC, MySQL and WMS providers. The SHP provider will be updated to also follow this standard. The following table outlines the Open Source class names that are bow used for the 3.2 version of the FDO SHP Provider.
|
3.0 Class Name |
3.2 Class Name |
|
|
|
|
FdoShpClassCollection |
FdoShpOvClassCollection |
|
FdoShpClassDefinition |
FdoShpOvClassDefinition |
|
FdoShpColumnDefinition |
FdoShpOvColumnDefinition |
|
FdoShpPhysicalSchemaMapping |
FdoShpOvPhysicalSchemaMapping |
|
FdoShpPropertyDefinition |
FdoShpOvPropertyDefinition |
|
FdoShpPropertyDefinitionCollection |
FdoShpOvPropertyDefinitionCollection |
|
|
|
Several FDO API files have had their names changes to conform to the common file naming convention or to remove GIS from their filenames.
|
3.0 File Name |
3.2 File Name |
|
GisCommon.h |
FdoCommon.h |
|
GisGeometry.h |
FdoGeometry.h |
|
GisMessage.h |
FdoMessage.h |
|
common/Types.h |
Common/FdoTypes.h |
|
common/GisPtr.h |
Common/Ptr.h |
|
common/GisSemaphore.h |
Common/Semaphore.h |
|
common/GisStd.h |
Common/Std.h |
|
common/GisStringp.h |
Common/Stringp.h |
|
fdo/FdoCollection.h |
Common/Collection.h |
|
fdo/FdoException.h |
Common/Exception.h |
|
Geometry/AgfGeometry/AgfGeometryFactory.h |
Geometry/Fgf/Factory.h |
|
Spatial/GisSpatialGeometryValidity.h |
Spatial/SpatialGeometryValidity.h |
|
Spatial/GisSpatialGridTransform.h |
Spatial/SpatialGridTransform.h |
|
Spatial/GisSpatialStd.h |
Spatial/SpatialStd.h |
|
Spatial/GisSpatialUtility.h |
Spatial/SpatialUtility.h |
|
|
|
In Version 3.2, the FDO Open Source API reference documentation will be generated using Doxygen. API documentation content will retrieved directly from the header files that constitute the public FDO API.
In FDO 3.2, additional capabilities support was added to the FDO API for the following use cases.
· Identify if the provider supports write.
· Identify size limits of various schema elements such as maximum name sizes and string sizes.
· Identify the characters that are not valid for schema element names.
· Support specifying explicit geometry types allowed for a geometry property.
The main addition is to indicate whether the data store is read-only or can support write. By adding a SupportsWrite() capability, the client can find out if the provider is read-only. Note that this is related to being able to update data and does not include schema modifications. There is an existing separate schema capability for supporting schema modification.
A related addition is a capability indicating if the provider supports multi-user update, i.e. for a provider that supports write, whether more than one user can update the data store at the same time. For example, a file-based data store may be updatable, but only one user at a time whereas a database can support multiple update users at one time.
To support the above objectives, two additional capabilities were added to FdoIConnectionCapabilities, with the following methods:
// Returns true if write is supported by the provider
virtual FDO_API bool SupportsWrite()=0
// Returns true if the provider can support more than one user writing to a single data store at one time
virtual FDO_API bool SupportsMultiUserWrite=0
If write is not supported, then locking, transactions, and multi-user write would also not be supported. If multi-user write is supported then write is supported.
Changes were made for Expression capabilities in order to deal with definitions of overloaded functions. An additional change was to add a flag to identify aggregate functions from simple functions. E.g. Max() is an aggregate functions that computes a single result from a set of objects whereas Sqrt() is a simple function that operates on a single value.
To be able to support overloaded functions, we need a way to describe a set of function signatures.
E.g.
Int32 Max(Int32)
Double Max(Double)
String Max(String)
Date Max(Date)
The enhancements define a signature structure and a signature collection structure which can be returned from a function definition.
In order to support the above concepts, a new class FdoSignatureDefinition was added to the FDO API with the following methods:
// Gets an array of FdoArgumentDefinition objects required for the function.
FDO_API FdoReadOnlyArgumentDefinitionCollection * GetArguments ()
// Gets the FdoPropertyType of the function return value
FDO_API FdoPropertyType GetReturnPropertyType ()
// Gets the FdoDataType of the function return value. This is only valid if the function return property type is FdoPropertyType_DataProperty
FDO_API FdoDataType GetReturnType()
In order to collect instances of FdoSignatureDefinition into a collection, a read-only collection FdoReadOnlySignatureDefinitionCollection was also added to the FDO API:
Finally, to FdoFunctionDefinition, the following methods were added:
// Gets an array of FdoSignatureDefinition objects that describe the different signatures supported by the function
FDO_API FdoReadOnlySignatureDefinitionCollection * GetSignatures ()
// Returns true if the function is an aggregate function and false if it is a simple function.
FDO_API bool IsAggregate()
For backwards compatibility, for the overloaded functions, the existing methods GetArguments() and GetReturnType() would return the same result as they do now. For the currently supported aggregate functions of min(), max(), avg(), ceil(), floor(), etc., the capabilities currently show that they take a double value argument and return a double value.
Additions were made to the FDO API Schema capabilities in order to be able to describe limits on name sizes and maximum value sizes.
The following are the additional limit information added to this set of capabilities.
· Maximum data store name size.
· Maximum schema name size.
· Maximum class name size.
· Maximum property name size.
· Maximum size of description.
· List of reserved characters for: data store name, schema name, class name, and property name.
A list of reserved characters rather than a list of valid characters was chosen because in the general case, a list of valid characters would be very long and difficult to determine a complete list when the various supported national languages are taken into account. The list of reserved characters is usually relatively small and easier to determine for sources such as Oracle, SQL Server, etc. This list is a list of wide-char characters.
There are two additional schema capabilities that are added.
· Supported properties that can be used for identity properties.
· Supports default value specification for a property.
Here is the enumerator for the name types.
enum FdoSchemaElementNameType:
|
FdoSchemaElementNameType_Datastore |
Data store name |
|
FdoSchemaElementNameType_Schema |
Schema name |
|
FdoSchemaElementNameType_Class |
Class name |
|
FdoSchemaElementNameType_Property |
Property name |
|
FdoSchemaElementNameType_Description |
Description field |
To FdoISchemaCapabilities add the following new functions:
// Returns the maximum size of a value of the given type. It includes class name size limits, property name size limits, description size limits, etc.
virtual FDO_API FdoInt32 GetNameSizeLimit (FdoSchemaElementNameType name)=0
// This returns a string that includes all the reserved characters that cannot be used for the various schema element names (e.g. data store name, class name, etc.) for the provider
virtual FDO_API FdoString * GetReservedCharactersForNames()=0
// Returns TRUE if default values can be specified for a data property definition and FALSE otherwise
virtual FDO_API FdoDataType * SupportsDefaultValue ()=0
// Gets a list of the property types that can be used for identity properties
virtual FDO_API FdoDataType * GetSupportedIdentityPropertyTypes (FdoInt32 &length)=0
There are also limits that apply to data properties that need to be exposed through the API
· Maximum precision for Decimal.
· Maximum scale for Decimal.
· Maximum length for String.
· Maximum length for BLOB.
· Maximum length for CLOB.
In order to support these limits, the following functions were added to FdoISchemaCapabilities.
// Gets the maximum supported length of String, BLOB, or CLOB data properties. For decimal,
// it would be the max scale plus max precision. For other data types that are not variable in size,
// the value returned is the byte length. Note that this returns int64 because some providers
// support blob lengths that won’t fit into int32
virtual FDO_API FdoInt64 GetMaximumDataValueLength (FdoDataType dataType)=0
// Gets the maximum supported precision for the Decimal data property.
virtual FDO_API FdoInt32 GetMaximumDecimalPrecision()=0
// Gets the maximum supported scale for the Decimal data property.
virtual FDO_API FdoInt32 GetMaximumDecimalScale()=0
For Geometry properties, the FDO API needed the ability to specify the specific geometry types that the property will support. Currently, even though the methods are called Set/Get GeometryTypes(), the settings are “geometric” types indicating point, linear, or area. These are not specific since linear can include polyline, multi-polyline, multi-curve, etc. Point can include either point or multi-point. For many cases, users need to specify a specific one or set of geometry types or determine the specify type that is allowed. E.g. for SHP data stores, the geometry has to be one specific type. If it’s point, then only point is allowed and not multi-point.
Unfortunately, the current methods use the name GeometryTypes, which would have been the obvious choice for a new set of methods. SpecificGeometryTypes was chosen instead. Therefore, the following FdoGeometricPropertyDefinition methods were added to the API.
// Gets the specific Geometry types that can be stored in this geometric property.
// The returned value is a list of the geometry types that are supported, with length
// being the number of types returned.
FDO_API FdoGeometryType* GetSpecificGeometryTypes (FdoInt32& length)
// Sets the specific set of Geometry types that can be stored in this geometric property.
// The value is a list of geometry types. Usually, one specific type is supported,
// but there can be more than one.
FDO_API FdoGeometryType* SetSpecificGeometryTypes (FdoGeometryType* types, FdoInt32 length)
If SetGeometryTypes() is used and then GetSpecificGeometryTypes() is called, the new method will return the complete list of geometry types that the geometric type allows. E.g. if the geometric type is FdoGeometricType_Point, then FdoGeometryType_Point and FdoGeometryType_MultiPoint will be returned from GetSpecificGeometryTypes(). For the other way around, if SetSpecificGeometryTypes() is called followed by GetGeometryTypes(), it will only return geometric types if all the related geometry types have been specified. E.g. it would show FdoGeometricType_Point only if both FdoGeometryType_Point and FdoGeometryType_MultiPoint are set. It is possible if no geometric type is completely specified that GetGeometryTypes will return 0.
Mappings from geometric types to geometry types
· Point: Point, MultiPoint.
· Linear: Linestring, MultiLineString, CurveString, MultiCurveString.
· Area: Polygon, MultiPolygon, CurvePolygon, MultiCurvePolygon.
· Solid: No geometry types exist for the solid geometric type.
· Point+Linear+Area: All of the above plus MultiGeometry.
Due to provider capabilities, the effective list of geometry types for a geometric type for a particular provider may be a subset of the above.
Add the following method to the FdoClassCapabilities Interface
// Returns true if the class supports write
FDO_API FdoBoolean SupportsWrite()=0
This enhancement is to provide a way for an FDO user to find out whether a provider is a file-based provider, database-based provider, or web server type of provider (e.g. WFS). Further, for file-based providers, it will provide a list of the dependent files for the data store. E.g. a SHP file contains a set of related files, .shp, .prj, .dbf, etc.
While most providers are of a single type, e.g. SDF provider is always a file provider, and Oracle is always a database provider, some providers such as ODBC and OGR would vary depending on the specific connection.
There will be cases with ODBC and presumably OGR and FME providers where it will be difficult for the provider to determine the exact data store type due to an extra access layer between the provider and the data. A connection to ODBC is via DSN or ODBC driver specific connection string. If a DSN we would have to try to get the relevant file vs. server information from the ODBC Driver Manager. This may not be straight-forward. This will need to be analyzed. If a connection string we will have to parse the string to find a DSN or determine if a file is specified. This also may be difficult to do especially since the connection string keywords maybe somewhat driver specific.
As a result, we may have situations where the ODBC provider will not know if a local file is used or if a server is used. For these cases, the provider will return an “unknown” data store type.
This enhancement adds the following methods to the FdoIConnectionInfo interface.
// Returns the data store type supported by the current connection of the provider
FDO_API FdoProviderDatastoreType GetProviderDatastoreType()=0
// Get a list of the dependent files for the current connection for file-based data stores.
// File names include full path qualification.
FDO_API FdoStringCollection* GetDependentFileNames()=0
Add an FdoProviderDatastoreType enumerator:
enum FdoProviderDatastoreType:
|
FdoProviderDatastoreType_Unknown |
Unknown type. |
|
FdoProviderDatastoreType_File |
File-base data store. |
|
FdoProviderDatastoreType_DatabaseServer |
DBMS data store. |
|
FdoProviderDatastoreType_WebServer |
Web server. |
Some providers support a connection to a file directory, e.g. SHP provider. In this case, the list of dependent files would include all the relevant files in the directory that are used for that data store. If the directory contains additional files that don’t make up the data store, e.g. .doc files, they are not included in the list. If there is a configuration file in the directory for the SHP data store, it is included in the list.
The file names returned will include full path qualification.
Requesting the list of dependent files for a non-file type provider will result in a null pointer returned.
The list of dependent files would only be available once the connection is opened.
The current FDO providers fall into the following types:
* - These could be either file or database server depending on the specific connection.