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 Date | 12 August 2014 |
Last Modified | 12 August 2014 |
Author | Jackie Ng |
RFC Status | ready for review |
Implementation Status | pending |
Proposed Milestone | FDO 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 useOGRLayer::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 ifDataStore
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