WL#10827: Ellipsoidal R-tree support functions

Affects: Server-8.0   —   Status: Complete   —   Priority: Medium

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.

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.