ARK2/Spatial - Revision history

John Layt: /* Design */

2021-09-21T16:00:29Z

‎Design

2021-09-21T15:58:22Z

‎Platform Support

2017-02-01T14:05:04Z

‎Platform Support

2017-02-01T11:18:51Z

‎Platform Support

2017-01-25T10:35:58Z

‎Design

2017-01-24T19:59:17Z

‎Implementation

2016-12-25T12:44:56Z

‎Design

2016-12-25T12:08:51Z

‎Design

2016-11-27T20:34:52Z

‎Implementation

2016-11-27T20:05:23Z

@@ Line 24: / Line 24: @@
 Again, support for spatial search and processing is uneven:
 * MySQL supports standard SQL spatial functions from 5.6 onwards, and spatial indexes for InnoDB from 5.7.6 onwards
-* MariaDB supports standard SQL spatial functions from 5.5 onwards, but no spatial indexes for InnoDB yet
+* MariaDB supports standard SQL spatial functions from 5.5 onwards, and spatial indexes for InnoDB from 10.2.2 onwards
 * Both MySQL and MariaDB support spatial indexes in MyISAM from 5.5 onwards
 * PostgreSQL and SQLite support spatial functions but only by adding extensions (PostGIS and Spatialite)

@@ Line 55: / Line 55: @@
 * MySql >= 5.5 supports 2D geometry & MyISAM spatial index, >= 5.6 spatial processing, >= 5.7.6 for InnoDB spatial indexing
-* MariaDB >= 5.5 supports 2D? geometry and spatial processing natively, no spatial index in InnoDB
+* MariaDB >= 5.5 supports 2D? geometry and spatial processing natively, spatial index in InnoDB >= 10.2.2 https://mariadb.com/kb/en/mysqlmariadb-spatial-support-matrix/
 * PostGIS native 3D geometry, spatial index, and spatial processing
 * Spatialite native 3D geometry, spatial index, and spatial processing

@@ Line 54: / Line 54: @@
 == Platform Support ==
-* MySql >= 5.5 supports 2D geometry, >= 5.6 spatial processing, >= 5.7.6 for InnoDB spatial indexing
+* MySql >= 5.5 supports 2D geometry & MyISAM spatial index, >= 5.6 spatial processing, >= 5.7.6 for InnoDB spatial indexing
 * MariaDB >= 5.5 supports 2D? geometry and spatial processing natively, no spatial index in InnoDB
 * PostGIS native 3D geometry, spatial index, and spatial processing

@@ Line 54: / Line 54: @@
 == Platform Support ==
-* MySql >= 5.5 supports 2D geometry, >= 5.6 spatial processing, >= 5.7.6 for spatial indexing
+* MySql >= 5.5 supports 2D geometry, >= 5.6 spatial processing, >= 5.7.6 for InnoDB spatial indexing
 * MariaDB >= 5.5 supports 2D? geometry and spatial processing natively, no spatial index in InnoDB
 * PostGIS native 3D geometry, spatial index, and spatial processing

@@ Line 34: / Line 34: @@
 * On PostgreSQL and SQLite if GEOS is available then it will be used on the original data
 * Otherwise spatial search and processing will be unavailable
 A useful side-effect of this strategy is that the spatial search table could be stored on a separate database server, such as a local Spatialite instance or a shared PostGIS server.

@@ Line 41: / Line 41: @@
 == Implementation ==
-A number of OpenGIS complint libraries do exist, but none that meet our full requirements:
+A number of OpenGIS compliant libraries do exist, but none that meet our full requirements:
 * https://github.com/brick/geo - OpenGIS geometry library, requires GEOS, MySQL, PostGIS, or Spatialite. Has WKT and WKB support, but no file import/export support. Provides DBAL data types. Current but low-level maintenance, but not widely used.
 * https://github.com/phayes/geoPHP - OpenGIS geometry library, internal routines but supports GEOS, lots of basic file import/export 2D only, effectively unmaintained but widely used, would need to fork and do major cleanups.
 * https://github.com/symm/gisconverter (and several others) - Various file importer libraries with partial OpenGIS class support but no functions.

@@ Line 37: / Line 37: @@
 A useful side-effect of this strategy is that the spatial search table could be stored on a separate database server, such as a local Spatialite instance or a shared PostGIS server.
-Idea to investigate: if using Redis for cache, then has geospatial cache which can be used, e.g. for the museum authority areas as well as the spatial search.
+Idea to investigate: if using Redis for cache, then has geospatial cache which can be used for spatial search in bounding box or radius.
 == Implementation ==

← Older revision		Revision as of 12:08, 25 December 2016
Line 36:		Line 36:

	A useful side-effect of this strategy is that the spatial search table could be stored on a separate database server, such as a local Spatialite instance or a shared PostGIS server.		A useful side-effect of this strategy is that the spatial search table could be stored on a separate database server, such as a local Spatialite instance or a shared PostGIS server.
		+
		+	Idea to investigate: if using Redis for cache, then has geospatial cache which can be used, e.g. for the museum authority areas as well as the spatial search.

	== Implementation ==		== Implementation ==