Download the PHP package glaivepro/sf without Composer
On this page you can find all versions of the php package glaivepro/sf. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Package sf
Short Description SFA-SQL expression builder
License MIT
Homepage https://github.com/glaivepro/php-sf
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package sf
PHP Simple Features SQL
Build SFA-SQL (SQL/MM) expressions using SFA-CA syntax.
Note Currently this doc contains not only description of this package and documentation sketch, but plans and research as well. WIP. Unreleased.
Simple Features is a standard (multiple standards actually) by Open Geospatial Consortium defining models for geospatial data. The standard defines object oriented and SQL access (known as SFA-SQL, SQL/MM and ArcSDE among others) to these models. This package implements the object oriented SFA API in PHP and produces SFA-SQL expressions from it.
It can be used to build SQL statements for systems such as PostGIS, SpatiaLite, MySQL spatial and others implementing SFA-SQL or SQL-MM.
Feature examples
The objects in this lib allow chaining SFA to create SQL expressions:
You can also specify columns:
Raw expressions can be prevented from going to bindings by wrapping them in an Expression object:
Initiate objects using constructors
Use grammar-specific constructors and methods:
Use factories with drivers set on them:
If you can't use bindings, you can use the quoting mode:
Usage examples
This section presents some plain examples in plain PDO.
Query a relation between columns yard and road:
Query a column against a raw statement:
Set a value:
Scope and goals
The main goal is to support creation of PostGIS expressions which follows the ArcSDE implementation. If method names are different, we should have aliases to support PostGIS naming. If arguments are different, we should strive to support all cases.
MySQL, MariaDB and SpatiaLite support would also be nice.
However, at this point in time, this is not supposed to be a compatibility layer between the databases. If the same function does different things on different databases, we are not homogenizing the behaviour. We just let you call the function as is.
A homogenization layer might be useful, but that's another step, after the raw builder.
Roadmap
- Document internals (class, trait & contract modelling; callFromMethod, wrap etc)
- All the SFA model
- All the other SFA-SQL functions
- Internal support for return and arg types (e.g.
IntExpression,AreaExpression) - PostGIS specific stuff like constructors, additional args, geography stuff and so on
- Testing support, including a SpatiaLite driver and ability to replace "drivers"
- Laravel query builder and Eloquent (casts, setting, queries...) integration
- MariaDB support
Architecture
Some implementation details to help organizing the stuff.
Expressions
The main building block is the Expression class that represents an SQL
expression along with bindings. All the geometry classes are subclasses of
Expression. All expressions have two public properties and they are stringable:
There are three ways to create any expression object:
Expression subclasses
The goal of expression subclasses is to know what type of object we are dealing with and what methods are available on it.
Currently we only have expression subclasses for geometry, but we might have other types (integer valued expression, area valued expression and so on) later.
Geometry class
In addition to base Expression tools, Geometry (and all the GIS subclasses) has these helpers:
Hierarchy and composition
The geometry class hierarchy as defined in the OGC spec along with the required
methods is defined in interfaces in OGC\Contracts.
The default mapping from OOP methods to SQL as described in the OGC spec is
implemented in OGC\Traits.
The classes are built somewhat like this (pseudocode):
We also include classes in the OGC namespace that implement everything as
defined in the spec. Seemingly there are no DBMSs that implement everything
exactly like that, but let it be for now.
Btw if an OGC-defined method is not implemented in the particular DBMS, you will get a MethodNotImplemented exception thrown.
Constructors
Constructors are implemented in classes named Sfc (simple feature constructor).
You have the defaults in OGC\Sfc:
And the more specific stuff in the specific Sfcs:
The Sfc classes also have the [type]FromMethod magic methods, e.g.
Which is useful when you want to share functionality across Sfc classes but need to return a geometry class belonging to the particular DBMS.
Terminology and references
- SF — Simple Features, the geometries and the interface to interact with them.
- SFA — Simple Feature Access, same thing as Simple Features.
- OGC — Open Geospatial Consortium
- SQL/MM — SQL multimedia schema defined by ISO/IEC 13249, including SQL/MM spatial defined in ISO/IEC 13249-3.
- SFA-CA — Geometry model defined by OGC in SFA part 1
- SFA-SQL — SQL schema for simple features defined by OGC in SFA part 2
- ArcSDE — the thing in ArcGIS suite that communicates with a relational database. Some RDBMS treat it as a de facto standard and sometimes follows it over SFA (dropping SFA methods that ArcSDE is not using https://trac.osgeo.org/postgis/changeset/8680) or SQL/MM (implemented for ArcSDE not SQL/MM https://postgis.net/docs/ST_OrderingEquals.html).
Our API mainly tries to support the OpenGIS SFA standard, but it might also include some common aliases from ArcSDE and others.
The supportable SQL is described in multiple standards and other resources:
- OpenGIS SFA part 2
- SQL/MM (ISO/IEC 13249-3), no free access
- ArcSDE
- PostGIS
Some might also be interested to see ISO 19125 (SFA), ISO/IEC 13249-3 (SQL/MM spatial) and ISO 19107 (spatial schema).
Similar projects
brick/geo
Allows doing GIS stuff inside PHP, using an underlying engine like GEOS ext, PostGIS and others. Includes SF query engines for various databases.
brick/geo-doctrine
https://github.com/brick/geo-doctrine
GIS mappings for Doctrine and functions for DQL.
GeoPHP
Does GIS stuff inside PHP and allows communicating with DB using WK and other formats.
vincjo/spatialite
https://github.com/vincjo/spatialite
PHP interface to SpatiaLite.
elevenlab/php-ogc
https://github.com/eleven-lab/php-ogc
Implementation of SFA types in PHP.
elevenlab/laravel-geo
https://github.com/eleven-lab/laravel-geo
Extending Laravel query builder and Eloquent with some of the SFA-SQL methods.
mstaack/laravel-postgis
https://github.com/mstaack/laravel-postgis
Implementation of SFA types with custom interface and support for those objects in Eloquent. Also adds support for these types in migrations.
geo-io/geometry
https://github.com/geo-io/geometry
Implementation of SFA object oriented features in plain PHP. Part of project Geo I/O that includes other Geo PHP tools as well.
jsor/doctrine-postgis
https://github.com/jsor/doctrine-postgis
PostGIS support for Doctrine, see the supported functions. We should strive to support the same.
