[6.x] Added support for separation between geometry and geography types

[raymondtri]

When using postgres with postgis-created types.

This is very important as without these changes, you are pigeon-holed into having to use geography spatial types only.

The problem with this has many facets, one being that generally geometry should be used over geography. Defaulting to the more advanced type also limits the availability of functions included in PostGIS. For more information on the advantages versus disadvantages, the PostGIS literature dives into it here.

With this in mind, the default PostGIS types have been switched to geometry instead of geography. To enable geography, a fluent property is available, which defaults to SRID 4326:
$table->column('col')->geography()

Furthermore, users will now be able to specify spatial reference schemas for projection purposes (which has been available since PostGIS 2.2 (released 2015) and above). You can even add your own spatial reference systems if you decide you want to do spatial geography for non-earth environments. This is made available via the ->projection fluent property, and available on both geography and geometry types.

A geometric type existing in 4326:
$table->column('col')->projection(4326)
A geographic type existing in 4326:
$table->column('col')->geography()->projection(4326)

To keep things simple, there are some defaults (for instance, geographies must have a spatial reference system, but default to SRID:4326.

[raymondtri]

In an effort to make this non-breaking for 6.x (breaking change moved to 7.x PR) to provide support for specifying a geometry type:

• The ->isGeometry fluent property has been added.
• The ->geography fluent property is removed
• The ->projection fluent property is still recognized

[GrahamCampbell]

I think it would be less confusing to only implement this on 7.x.

[raymondtri]

It would be less confusing, howerever there should be a way to use the PostGIS-recommended geometry data types, without needing to build a custom grammar package.

This is especially important in the LTS version of Laravel, when the change is very simple if implemented inside of Laravel.

[driesvints]

Closing this because of the breaking change.

[raymondtri]

@driesvints I refactored this in #94b9da7 so it would be non-breaking, can you tell me where it is breaking?

[driesvints]

@raymondtri you're correct, apologies.