FDO RFC 42 - Direct ArcSDE FDO Provider

This page contains a request for comments document (RFC) for the FDO Open Source project. More FDO RFCs can be found on the RFCs page.


RFC Template Version(1.0)
Submission Date 17 October 2009
Last Modified Crispin Hoult 17 October 2009
AuthorCrispin Hoult, Alan Douglas, Haris Kurtagic
RFC StatusAdopted
Implementation StatusInternal Prototype / Proof of Concept / Build Candidate
Proposed Milestone 3.5.0
Assigned PSC guide(s) Greg Boone
Voting History
+1Jackie Ng, Haris Kurtagic, Jason Birch, Traian Stanev, Frank Warmerdam
+0Greg Boone, Orest Halustchak


The purpose of the RFC is to provide a direct provider for SDE datasources in Oracle without the requirement to utilise the ESRI ArcSDE SDK or ArcSDE server service.


ArcSDE is the most common "enterprise" geospatial database engine encountered by 1Spatial in solution deployment. Of these datastores the majority are on an Oracle platform with data in the ESRI SDE binary format. An overview of the format can be found in "Resources"details below. It is recognised that there is an existing OSGeo provider for ArcSDE data (ArcGIS servers 9.1, 9.2 and 9.3 at FDO 3.4). The existing provider supports multiple connection methodologies (client and direct-connect), data types (SDE and SDO on Oracle) and server technologies (Oracle, SQLServer). However the platform technology (SDK/API) this is based on causes issues for the ongoing support and development outlined below.

The provision and adoption of a new provider is no small task, and the creation of one that parallels existing functionality requires some explanation. The drivers behind this RFC are as follows:

  • The existing OSGeo ArcSDE provider builds on the ArcSDE SDK - this is a commercial offering from ESRI and it's cost and install-base limit community involvement in the open source support and maintenance of the provider
  • The use of the ArcSDE SDK requires a more complex implementation/deployment of the FDO provider where the relevant supporting ESRI client DLLs need to be obtained and copied to the FDO folder - this adds version support issues and client licensing questions into implementation
  • The use of the ArcSDE SDK is built against specific versions of the ArcSDE server and SDK - there is a reliance on ESRI to support new server versions (e.g. ArcGIS 9.3) in the SDK and on the current owner (OSGeo) to source and rebuild appropriately and timely
  • The use of the ArcSDE SDK utilises calls directly to the ArcSDE server - where a partner has a restricted ArcSDE license is ("Application Specific License") there are licensing issues relating to the current provider and use of the ArcSDE server
  • The use of the ArcSDE SDK is limited to 32-bit builds of the provider - there is a wider requirement to have a 64-bit provider for ArcSDE data and the current approach does not support this

With consideration of the current providers limitations above the motivation for a non SDK-based provider are proven and this RFC details the proposed solution below.

Proposed Solution

The initial set of functionality for this provider will include

  • Support for simple geometries
  • Limited capabilities support for spatial and attribute filters (no expression evaluation)
  • Support for select/sqlcommand only (no insert/update/delete)
  • Limited platform support to Oracle database

Specific capabilities are built on the KingOra platform and are therefore identical. As capabilities are defined at the provider level and not based on the connection parameters some consideration will have to be given to the "SDE Schema" connection being more constrained than a pure KingOra SDO connection


  • ThreadCapability: PerConnectionThreaded
  • SpatialContextExtent: Static
  • SupportsLocking: : false
  • SupportsTimeout: : false
  • SupportsTransactions: : false
  • SupportsLongTransactions: : false
  • !SupportsSQL: : true
  • SupportsConfiguration: : true


  • Class
    • FeatureClass
    • Class
  • Data
    • Boolean
    • Byte
    • DateTime
    • Decimal
    • Double
    • Int16
    • Int32
    • Int64
    • Single
    • String
  • SupportsInheritance: false
  • SupportsMultipleSchemas: true
  • SupportsObjectProperties: false
  • SupportsAssociationProperties: false
  • SupportsSchemaOverrides: true
  • SupportsNetworkModel: false
  • SupportsAutoIdGeneration: false
  • SupportsDataStoreScopeUniqueIdGeneration: false
  • SupportedAutoGeneratedTypes: false
  • SupportsSchemaModification: false


  • SupportedCommands
    • Select
    • SQLCommand
    • DescribeSchema
    • GetSpatialContexts
    • CreateSpatialContext
  • SupportsParameters: true
  • SupportsTimeout: false
  • SupportsSelectExpressions: true
  • SupportsSelectFunctions: true
  • SupportsSelectDistinct: true
  • SupportsSelectOrdering: true
  • SupportsSelectGrouping: true


  • Condition
    • Comparison
    • Like
    • In
    • Null
    • Spatial
  • Spatial
    • Intersects
    • EnvelopeIntersects
  • SupportsGeodesicDistance: false
  • SupportsNonLiteralGeometricOperations: false


  • Function
    • SpatialExtents


  • SupportsRaster: false
  • SupportsStitching: false
  • SupportsSubsampling: false


  • SupportsTopology: false
  • SupportsTopologicalHierarchy: false
  • BreaksCurveCrossingsAutomatically: false
  • ActivatesTopologyByArea: false
  • ConstrainsFeatureMovements: false


  • Types
    • Point
    • LineString
    • Polygon
    • MultiPolygon
  • Components
    • LinearRing
  • Dimensionality: 2


The main limitations of this provider at present are the following. It is envisioned that community support and development can extend the provider into these areas:.

  • No support for complex geometries or curves
  • Only SDE datastores on Oracle will be accessed
  • The provider will only be tested on SDE 9.1 and 9.2 schemas with geometry in "normal" precision (64-bit "high" precision not supported - yet)
  • There will be no expression support
  • There will be no insert/update/delete capability (read-only provider)
  • The spatial expressions will be restricted
  • Indexing/performance will be based on simple bounding-box filters
  • Spatial queries will be based on simple bounding-box filter


This provider does not require any API changes to the FDO core or other providers. It will need to be added to the standard build and test procedure.

Test Plan

The Direct SDE Provider for ArcSDE will include unit tests. Unit tests will be run against a sample SDE schema dumped, Oracle exported and imported. The provider will be built as a trunk (3.5) and 3.4 compatible provider and tested in AutoCAD Map 2010 and MapGuide OpenSource 2.1 Where reources are available a FDO 3.3 build will also be provided.


The following list of resources will be used to support creation of the provider.


The resources for this provider are being contributed by 1Spatial with foundation (KingOra) and expertise by SL-King.

Last modified 15 years ago Last modified on Dec 9, 2009, 9:07:10 AM
Note: See TracWiki for help on using the wiki.