Laravel Mysql Spatial Laravel Package

Product Decisions This Supports

• Feature feasibility for location-based capabilities. This package is a thin Eloquent layer (casts + query scopes) over MySQL's native ST_* spatial functions. It lets you answer "should we build proximity search / store locator / delivery-radius filtering / point-in-polygon zone checks?" without a separate geo service. That makes it a cheap spike tool: one engineer, one sprint, a real answer on performance and data quality.
• Build vs. buy vs. wrap decision. The decision is not "adopt or reject this library" — it's "do we want geo logic expressed in the Eloquent model layer at all?" Options: (a) this package, (b) the actively maintained successor matanyadaev/laravel-eloquent-spatial (MySQL 8 + Postgres/MariaDB, current Laravel), (c) raw DB::raw / selectRaw with ST_Distance_Sphere, (d) a dedicated geo store (PostGIS, or a search index like Meilisearch/Elasticsearch geo). The package's real value is in demonstrating the schema and query patterns you'd otherwise hand-roll.
• Data model and indexing commitments. Choosing POINT/POLYGON columns with a fixed SRID (vs. plain lat/lng decimals) is a one-way-ish door: it affects spatial index viability, reporting/BI tooling, and vendor portability. Spatial indexes in MySQL also require NOT NULL columns and InnoDB — a constraint that surfaces as a schema decision, not a code decision.
• Roadmap prioritization of geo as differentiator vs. table stakes. If geo search is a "checkbox" feature (most SaaS store locators), MySQL spatial + this package is proportionate. If geo is core IP (routing, isochrones, geofencing for compliance or pricing), the ceiling here is low and you should be budgeting for PostGIS or a geo vendor instead.
• Expansion and compliance scoping. Territory/zone definitions support decisions like regional availability, licensing boundaries, and "can we serve this postcode?" gating — often the first place a PM actually needs polygons rather than points.
• De-risking a dependency. With a last release in October 2020, 804 stars, and effectively no tracked dependents, the useful PM decision is "quarantine and fork" vs. "migrate." That's a maintenance-budget line item, and it should be decided now rather than discovered during a Laravel upgrade.

When to Consider This Package

Consider it when:

• You are on MySQL 5.7/8.0 and a Laravel version this release actually targeted (roughly Laravel 6–8 era). Verify against composer.json before committing — do not trust the README.
• The geo need is bounded: point storage, distance-ordered "nearest to me" queries, bounding-box filters, and simple containment checks.
• You are doing a discovery spike and want idiomatic example code faster than reading MySQL spatial docs.
• You have the appetite to vendor/fork it — pinning the source into your repo, owning the upgrade path, and accepting that you are the maintainer of ~1–2k lines of glue.
• Volume and latency are modest; you're not doing sub-100ms geo queries at high QPS across millions of rows.

Look elsewhere when:

• You need PostgreSQL/PostGIS, MariaDB parity, or multi-database support — go to matanyadaev/laravel-eloquent-spatial, which is the maintained continuation and supports SRID-aware geography semantics properly.
• You are on Laravel 10/11 or PHP 8.2+ — an unreleased-since-2020 package is a compatibility gamble, and the failure mode (silent cast breakage) is worse than an outright error.
• You need anything beyond planar/naive distance: true geodesic accuracy at scale, routing, isochrones, geocoding/reverse-geocoding, tile serving. Those are service problems, not ORM problems.
• Licensing clarity is a gating requirement. GitHub reports NOASSERTION; the copyright and grant terms need a legal read before it goes into a commercial product. If your org requires an OSI-verified identifier, that alone may end the evaluation.
• Your team has no MySQL spatial experience — the package hides the casts, not the conceptual overhead (SRID mismatches and "distance in degrees vs. meters" bugs are the classic failure).

How to Pitch It (Stakeholders)

To executives: This is a free, small open-source library that lets our Laravel app store map coordinates and answer "what's near me" questions using the database we already run. It costs nothing to try and could let us ship location search in one sprint rather than buying a geo platform contract. The caveat is age: the last release was October 2020 and the project shows no active dependents, so we should treat it as a reference implementation to copy or fork, not a permanent dependency. Recommendation: fund a one-sprint spike to validate the feature and the query performance; if geo becomes a real product surface, budget a follow-on migration to the maintained fork or PostGIS. The decision we need from you is narrower than it looks — is location search a differentiator or table stakes? That answer determines whether we spend one sprint or one quarter.

To engineering: The package gives you Eloquent casts for POINT, POLYGON, LINESTRING, etc., plus query scopes for distance and containment, backed by MySQL's ST_* functions and spatial indexes. Assume you will own it: pin it, read the source, verify Laravel/PHP compatibility before adopting, and prefer matanyadaev/laravel-eloquent-spatial if you need a maintained path or Postgres. Watch the sharp edges — SRID consistency, NOT NULL requirements for spatial indexes, and the difference between planar and spherical distance. If you'd spend more time fighting the abstraction than writing selectRaw('ST_Distance_Sphere(...)'), skip the package and write the SQL.