[11.x] Make spatial types consistent

[hafezdivandari]

Spatial Data types was added on Laravel 5.5 via #21056 and had minor chnages on 5.7 and 6.0 (#25323 and #30545). During these years, MySQL, PostgreSQL (via PostGIS), SQLServer and SQLite (via SpatiaLite) databases have better and more stable support for spatial types. This PR make the support for these types consistent across all supported databases, you may also consider this as a behavioral fix in some way!

Notes

• MySQL now has better support for spatial types and geographic calculations since version 8.0
• PostgreSQL Spatial Data types added on Laravel 5.5, requires PostGIS extension but is not noted on the docs.
• SQLite doesn't have native support for spatial types, you may use the SpatiaLite extension for this. This extension doesn't support adding geometry columns during creating tables but you have to call AddGeometryColumn() method after creating the table. So the geometry and geography types for SQLite on Laravel are kept for backward-compatibility, testing purposes, and consistency.
• SQL Server has both geometry and geography types.

Why?

• The usage of these types are currently inconsistent across DBs and the result is hard to predict.
• The geometry defaults to geography which is confusing.
• PostgreSQL has native geometrics types (point, line, lseg, box, path, polygon, and circle), that has conflict with implemented PostGIS types (the point and polygon types). This PR fixes this.
• Using PostGIS, there are almost 48 subtypes available for geometry and 21 subtypes for geography that was impossible to be used on Laravel. The new implementation on this PR fixes this.
• All spatial types on SQL Server was mapped to geography although SQL Server has geometry type too. This PR fixes that.

Changes

• Changes geometry type to accept subtype (default null) and srid (default 0) :

  $table->geometry('column_name', subtype: 'point', srid: 0);`

  • MySQL subtypes: null (i.e. geometry), point, lineString, polygon, geometryCollection, multiPoint, multiLineString, multiPolygon
  • PostGis subtypes: null, point, lineString, polygon, geometryCollection, multiPoint, multiLineString, multiPolygon, linearRing, polyhedralSurface, triangle, tin, circularString, compoundCurve, curvePolygon, multiCurve, multiSurface with added suffixes Z, M and ZM.
• Adds geography type that accepts subtype (default null) and srid (default 4326):

  $table->geography('column_name', subtype: 'point', srid: 4326);`

  • MySQL subtypes: null (i.e. geometry), point, lineString, polygon, geometryCollection, multiPoint, multiLineString, multiPolygon
  • PostGIS subtypes: null, point, lineString, polygon, geometryCollection, multiPoint, multiLineString, multiPolygon with added suffixes Z, M and ZM.
• Removes point, lineString, polygon, geometryCollection, multiPoint, multiLineString, multiPolygon, and multiPolygonZ explicit types.
• Removes ->isGeometry() and ->projection() modifiers from PostgreSQL.

Upgrade guide

Likelihood Of Impact: Low

The geometry and geography column types of database migrations have been rewritten to make these types consistent across all databases, Therefore, you may remove point, lineString, polygon, geometryCollection, multiPoint, multiLineString, multiPolygon, and multiPolygonZ types from your migrations and use geometry / geography types instead:

- $table->point('geo');
// `geography(POINT,4326)` on PostgreSQL, `POINT` on MySQL and `geography` on SQL Server
+ $table->geography('geo', 'point');
// `geography(POINT,4326)` on PostgreSQL, `POINT SRID 4326` on MySQL and `geography` on SQL Server
+ $table->geometry('geo', 'point');
// `geometry(POINT)` on PostgreSQL, `POINT` on MySQL and `geometry` on SQL Server

[taylorotwell]

@hafezdivandari could you send a PR to migration docs and upgrade docs master branch to document this?

[hafezdivandari]

@taylorotwell sure.