wiki:FDORfc69

FDO RFC 69 - Enhanced OGR 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.

Status

RFC Template Version(1.1)
Submission Date12 August 2014
Last Modified12 August 2014
AuthorJackie Ng
RFC Statusready for review
Implementation Statuspending
Proposed MilestoneFDO vNext
Assigned PSC guide(s)
Voting History
+1
+0
-0
-1

Overview

This RFC is for enhancing the capabilities of the OGR provider and improving its reliability

Motivation

The OGR provider is very barebones in terms of FDO capabilities, this makes it difficult to author layers from OGR Feature Sources in MapGuide? as we can only render/stylize from OGR feature attributes as-is as the provider lacks support for FDO expression functions that let us format/shape this data during layer stylization.

Also the OGR provider lacks a basic unit test suite, which gives us no objective baseline as to the reliability of this particular provider.

Proposed Solution

The OGR provider will be enhanced with FDO Expression Engine support. The OGR expression capabilities will now return the full suite of functions supported by the FDO Expression Engine.

The Expression Engine will be used for both Select and SelectAggregates? commands. However, use of the Expression Engine will only happen outside of the following cases:

  • SelectAggregates? with single property or aggregate function and no FDO Filter
    • Count() will internally issue the following OGR SQL: SELECT count_expr FROM feature_class
    • SpatialExtents() will internally use OGRLayer::GetExtent(). Where supported, fast extent (bForce = FALSE) is used. Otherwise we brute force (bForce = TRUE)
    • Single property with distinct = true will internally issue the following OGR SQL: SELECT DISTINCT prop_name FROM feature_class
  • Select
    • Expression Engine will not be invoked if the select command has no computed identifiers

This RFC will also fix some defects in the provider that either already existed or were discovered during the implementation of this RFC:

  • #885: Use fast extent where possible for FdoISpatialContextReader::GetExtent()
  • FdoIConnection::Open() should fail if DataStore property is not specified
  • Executing any FDO Command should fail if connection is not open
  • OGRLayer pointers do not have their internal iterators reset before select/insert/update/delete, causing potential inconsistent results when executing multiple FDO select/insert/update/delete commands in succession on the same connection
  • Update commands always returned 0 features affected

We will also implement a basic unit test suite for the OGR provider to exercise Expression Engine support and key provider functionalities.

This RFC is implemented in the OGR sandbox. Upon adoption of this RFC, this sandbox will be merged into trunk.

Test Plan

Ensure the new test suite passes on both Windows and Linux.

Funding/Resources

Community

Last modified 3 years ago Last modified on Aug 19, 2014 3:52:05 AM