Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[6.x] Added support for separation between geometry and geography types #30545
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:
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:
To keep things simple, there are some defaults (for instance, geographies must have a spatial reference system, but default to SRID:4326.
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:
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.