[fdo-users] Few questions on OSGeo.MySQL.3.1

Gavin Cramer gavin.cramer at autodesk.com
Mon Oct 1 10:41:53 EDT 2007

For question 1, a provider's spatial filtering capabilities are reported
in by FdoIFilterCapabilities::GetSpatialOperations.  MySQL's
implementation of this method is

It currently reports EnvelopeIntersects and Intersects as being

This may seem like a short list, but note that MySQL does not support
the kind of detailed spatial filtering that you might expect.  It is
easy to overlook this, and it shows up in a number of forums.  MySQL has
many operators, but only implements them using MBR-based filtering.  FDO
delegates to MySQL's filtering.  See
ionships-between-geometries.html where it notes this limitation.

I hope that that MySQL documentation is still up-to-date.  :-)  The
MySQL Provider currently maps all spatial filters to MySQL's
"MBRIntersects" method.


-----Original Message-----
From: fdo-users-bounces at lists.osgeo.org
[mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of Brent Robinson
Sent: Monday, October 01, 2007 10:16 AM
To: FDO Users Mail List
Subject: RE: [fdo-users] Few questions on OSGeo.MySQL.3.1

Hi Maksim,

To answer question 2, the storage engine can be customized but, if I
remember right, MySQL restricts geometry columns to residing in MyISAM
tables. Therefore, even though the MySQL provider supports customizing
the storage engine, the cases where it can actually be changed are

Customizing the storage engine can be done through the
IApplySchema::SetPhysicalMapping() function. This function takes an
FdoPhysicalSchemaMapping but you'd need to pass in the provider-specific
derivation (FdoMySQLOvPhysicalSchemaMapping).

FdoMySQLOvPhysicalSchemaMapping::SetStorageEngine() can be used to
change the storage engine for any tables that are created when the
schema is applied (tables that already exist are not affected). You must
also set the name of the FdoMySQLOvPhysicalSchemaMapping to the same
name as the feature schema being applied. The header for this class can
be found in providers/GenericRdbms/Inc/Rdbms/Override/MySQL.

Individual tables can be customized but this requires a hierarchy of
physical schema mappings. This can be done by adding an
FdoMySQLOvClassDefinition, for each class to customize, to the
FdoMySQLOvPhysicalSchemaMapping. An FdoMySQLOvTable must be added to
each FdoMySQLOvClassDefinition. FdoMySQLOvTable:: SetStorageEngine can
be used to set the storage engine used to create the table for the

Basically the physical schema mapping classes have the same hierarchy as
the feature schema classes, plus some extra leaf classes for customizing
the physical database objects created for each feature schema element.


-----Original Message-----
From: fdo-users-bounces at lists.osgeo.org
[mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of Maksim Sestic
Sent: Saturday, September 29, 2007 9:44 AM
To: fdo-users at lists.osgeo.org
Subject: [fdo-users] Few questions on OSGeo.MySQL.3.1

Hi all,

I have a few questions related to Map 2007 SP3 FDO provider for MySQL

1) What spatial filters (operations) are actually supported? Are
SpatialOperations.SpatialOperations_Inside, Within, CoveredBy supported?
not, what's the most optimal way to find if something's inside something
else (say, inside a polygon)? :-)

2) I've noticed that MySQL provider creates generic (f_*) tables using
InnoDB mechanism. On the other hand, feature class tables are created
MyISAM. Assuming that InnoDB supports full ACID, are there any
parameters to
ApplySchema command to actually tell provider what type of MySQL storage

Maksim Sestic
View this message in context:
Sent from the fdo-users mailing list archive at Nabble.com.

fdo-users mailing list
fdo-users at lists.osgeo.org

fdo-users mailing list
fdo-users at lists.osgeo.org

More information about the fdo-users mailing list