WL#10827: Ellipsoidal R-tree support functions

Affects: Server-8.0 — Status: Complete

Description
Requirements
Dependent Tasks
High Level Architecture
Low Level Design

Currently, InnoDB R-trees support only Cartesian computations. This WL adds geographic support by reimplementing the R-trees support functions for MBR operations in sql/gis/rtree_support.{h,cc} in a way that supports both Cartesian and geographical spatial relation systems (SRSs). The WL also turns on geography support in spatial relation functions, so that spatial relation functions and R-tree computations are in sync.

User visible changes: Spatial relation functions (ST_Within, ST_Contains, etc.) will compute geographic results for geographic data.

R-tree

F-1.1: R-tree indexes on columns with Cartesian geometries MUST use Cartesian computations.
F-1.2: R-tree indexes on columns with geographic geometries MUST use geographic computations.
F-1.3: If an R-tree contains a mix of Cartesian and geographic geometries, or if any geometries are invalid, the result of any operation on that index is undefined.

Spatial relation functions

F-2.1: If any parameter is a geometry in a geographic SRS and a longitude value is not in the range (-180,180] (in degrees -- other limits in other units), the functions MUST raise ER_LONGITUDE_OUT_OF_RANGE.(*)
F-2.2: If any parameter is a geometry in a geographic SRS and a latitude value is not in the range [-90,90] (in degrees -- other limits in other units), the functions MUST raise ER_LATITUDE_OUT_OF_RANGE.(*)

(*) The exact limits will deviate slightly because of floating point arithmetics.

WL#8685: Ellipsoidal relational operations
WL#10439: Support SRID in InnoDB Spatial Index

I-1: No new files.
I-2: No new syntax.
I-3: No new commands.
I-4: No new tools.
I-5: Impact on existing functionality: Spatial relation functions (see WL#8685 for a list) will start using geographic computations if input geometries are in a geographic (ellipsoidal) spatial reference system.

R-tree support functions

Replace the homegrown function implementations with calls to Boost.Geometry.

MySQL-InnoDB interface

Before this WL, the R-tree support functions that InnoDB calls have an SRID parameter of type std::uint32_t. There are two problems with this:

The functions are called when there is no current_thd, which means that the functions can't look up the SRID in the data dictionary.
DD lookups are not cheap, so it reduces performance when each function has to look up the SRID.

Therefore, this WL modifies these functions to instead take a pointer to a dd::Spatial_reference_system object as parameter. The dict_index_t struct is extended with a new member rtr_str that is a std::unique_ptr to a clone of the DD's SRS object. Since the object is cloned, it's lifetime is not limited by the DD cache auto-releaser.

An alternative would be to store a similar, but different, structure to cache all the necessary properties of the SRS. This would reduce the DD dependency, but it would also duplicate a lot of the dd::Spatial_reference_system implementation. Using a clone of the dictionary object also makes it straight forward to pass the info to existing GIS functions that expect a DD SRS object.

Several internal R-tree functions in InnoDB are modified to pass along the SRS object pointer in order to make it available where rtree_support.h functions are called.

The cloned DD info is explicitly released in dict_mem_index_free.