Spine Trigonometric Dql Bundle Laravel Package

Product Decisions This Supports

• Location-aware feature delivery: adds SIN, COS, TAN, ACOS, ASIN, ATAN, RADIANS, DEGREES, PI (and typically ATAN2) to Doctrine's DQL, which is the missing primitive for computing great-circle distances and bearings inside SQL. That unblocks "stores near me," nearest-warehouse routing, radius filters, and map clustering without a separate geospatial stack (no PostGIS, no Elasticsearch geo queries).
• Build vs. buy vs. bolt-on: it lets you keep distance math in the query layer instead of pulling rows into PHP and filtering in application code — a meaningful performance and pagination decision for any "sort by distance" list view.
• Roadmap sequencing for geo features: a low-risk way to ship proximity search before committing to a dedicated geo service. It informs whether a geo initiative can be an incremental query change or a platform investment.
• Use cases it fits: store/ATM locators, delivery-radius eligibility, service-area checks, "closest technician" assignment, distance-based sorting in admin reporting, and any analytics requiring haversine or bearing in a report query.
• Anti-signal for product planning: near-zero adoption (0 stars, 0 dependents, score 0) means this is not a de-risked dependency. It should inform a "spike, don't standardize" recommendation rather than a roadmap commitment to a geo platform.

When to Consider This Package

Consider it when all of the following hold:

• You are on Symfony with Doctrine ORM (this is a Symfony bundle registering DQL functions via a compiler pass / config, not a Laravel package — despite the "Laravel/PHP" framing, there is no service provider or Laravel integration). In Laravel this would require Doctrine via a bridge such as laravel-doctrine.
• Your geo need is modest and query-shaped: a haversine distance expression, a bounding-box filter, a ORDER BY distance. You are not doing polygon containment, routing, or spatial indexing.
• Your dataset is small-to-moderate and indexed on latitude/longitude columns, so that a bounding-box prefilter in WHERE keeps the trig calls off the full table.
• Your team is comfortable vendoring or forking a small, unmaintained dependency. This is the realistic condition, not an optional one.

Look elsewhere when:

• You need real spatial capability — PostGIS/MySQL ST_Distance_Sphere, Sphinx/Elasticsearch geo, or a managed geo API. Those are faster, indexed, and far better supported.
• You are Laravel-first without Doctrine. Native Laravel/Eloquent has no DQL; use whereRaw with ST_Distance_Sphere or raw haversine SQL instead.
• You need maintenance guarantees. Zero stars, zero dependents, and no visible community means no security response, no PHP/Doctrine version compatibility guarantees, and no upstream fixes. Budget for owning the code.
• You need geodesic accuracy at scale — a naive spherical haversine on an ellipsoid-ish earth, or distance across the antimeridian, will not be handled by trig primitives alone.

How to Pitch It (Stakeholders)

For executives: We can add "stores near me" / "nearest location" capability with a small, focused library that extends our existing database query language with the math needed to compute distances. It avoids standing up a new geo platform and keeps the logic inside queries we already run, which means faster pages and less new infrastructure. The caveat is maturity: this is an unmaintained, essentially unused open-source component, so the real cost is not licensing but ownership — we should treat it as a spike and be prepared to vendor and maintain roughly a few hundred lines ourselves.

For engineering: This is a Symfony/Doctrine bundle registering trigonometric DQL functions — nothing Laravel-native. Value is precisely that it removes the "fetch all rows, compute in PHP" pattern for distance sorting and radius filters. Risks: unmaintained, no test/compat guarantees, and trig-in-ORDER BY defeats indexes, so require a bounding-box prefilter and a composite lat/lng index. Recommendation: 1–2 day spike against our current PHP and Doctrine versions; if it holds, vendor the function classes into our codebase with our own tests rather than depending on the upstream repo. If the spike surface friction or if the geo roadmap grows beyond "distance and sort," skip it and go to PostGIS or a geo search service.