Revision as of 17:53, 27 November 2016

Spatial

Basic spatial support is required, e.g. storing find points or area bounding boxes, as well as the advanced mapping interface options, such as displaying spatial layers, spatial search, etc.

Basic back-end support:

• Store EWKT as properties
• Validate EWKT
• Send/receive EWKT via API

Back-end support will utilise an OpenGIS standard compliant geometry library to manipulate and store basic geometries, support a basic level of geometry calculations, and provide data import/export.

• 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.

Likely solution will be to use Brick and fork various file libraries to work with it. May also fork geoPHP to work as a Brick backend? Alternative is major refactor of geoPHP, or piecemeal integration of each converter library.

Front-end support will continue to use OpenLayers.

Platform Support

• MySql >= 5.5 supports 2D geometry, >= 5.6 spatial processing, >= 5.7.6 for 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
• Spatialite native 3D geometry, spatial index, and spatial processing
• Postgresql no support, fake using WKT storage
• SQLite no support, fake using WKT storage
• GEOS provides spatial processing