wiki:FDORfc3

FDO RFC 3 - OSGeo PostGIS Provider Submission

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.

Status

RFC Template Version(1.0)
Submission Date 2007-05-04
Last Modified Jason Birch Timestamp?
AuthorMateusz Loskot, Jason Birch
RFC StatusAccepted
Implementation Status(under development)
Proposed Milestone 3.2.2
Assigned PSC guide(s) Jason
Voting History
+1Jason, Greg, Orest, Bob, Haris
+0
-0
-1

Overview

The purpose of this RFC is the introduction of a dedicated PostGIS FDO provider into the FDO project.

Motivation

PostGIS/PostgreSQL is recognised as the premier open source database solution for spatial applications, and is a highly desirable format for FDO to support. While a level of support for PostGIS is currently available with the OGR provider, creating a dedicated provider for PostGIS has considerable benefits. It allows for some specific optimisations and advanced features that are not supported by the OGR provider, and shows FDO's commitment to the dominant open source spatial database, encouraging adoption by a larger portion of the open source community.

Proposed Solution

Development version of this provider can be obtained from:

http://svn.refractions.net/fdopostgis/trunk/

This provider will be targeted at PostgreSQL version 8.2 and above, using PostGIS 1.1.6 and above. It may work with earlier versions, but they will not be tested.

The initial set of functionality for this provider will include

  • Support for all geometries except curves
  • Support for three-dimensionals
  • Support for full set of spatial and attribute filters
  • Support for select/sqlselect/insert/update/delete

Specific capabilities currently include (more coming before release: insert/update/delete/selectaggregate/applyschema):

Connection

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

Schema

  • 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: true
  • SupportsDataStoreScopeUniqueIdGeneration: false
  • SupportedAutoGeneratedTypes
    • Int32
    • Int64
  • SupportsSchemaModification: true

Command

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

Filter

  • Condition
    • Comparison
    • Like
    • In
    • Null
    • Spatial
  • Spatial
    • Contains
    • Crosses
    • Disjoint
    • Equals
    • Intersects
    • Overlaps
    • Touches
    • Within
    • CoveredBy
    • Inside
    • EnvelopeIntersects
  • SupportsGeodesicDistance: false
  • SupportsNonLiteralGeometricOperations: false

Expression

  • Basic
  • Function

Raster

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

Topology

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

Geometry

  • Types
    • Point
    • LineString
    • Polygon
    • MultiPoint
    • MultiLineString
    • MultiPolygon
    • MultiGeometry
  • Components
    • LinearRing
  • Dimensionality: 3D

Limitations

Apart from functionality that was not added due to resource constraints, the following conditions exist:

  • PostgreSQL tables and columns must be lowercase due to a deficiency in PostGIS (which should be fixed in 1.2.2)

Implications

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 procedures, and the process for acquiring the PostgreSQL libraries will need to be documented (unless we can distribute them with the provider)

Test Plan

This provider will be initially tested by the development group, and then opened up to public alpha/beta testing.

Areas that will require testing include:

  • capabilities
  • connection
  • all parts of schema description
  • apply schema
  • standard query
    • filters
    • expressions
  • SQL query
  • insert
  • update
  • delete

The FDO Provider for PostGIS will include unit tests. Additionally, as part of the development process a set of simple code samples is being created to allow new FDO developers to easily interact with the PostGIS provider.

Funding/Resources?

This provider is being jointly funded by Refractions Research and the City of Nanaimo. Development is being done by Mateusz Loskot.

Last modified 11 years ago Last modified on May 8, 2007 9:57:21 AM