Laravel Geographical Calculator Laravel Package

Product Decisions This Supports

• Service-area gating (point-in-area): the new containment check lets us answer "is this address/vehicle/user inside our delivery zone, licensed region, or coverage polygon?" directly in the Laravel app. This turns a recurring product question into a boolean we can ship in an existing endpoint, rather than a GIS integration project.
• Coverage and dispatch analysis (farthest point from a set): supports territory and logistics decisions — identifying the farthest customer/depot/asset from a hub, sizing service radii, flagging under-served regions, and choosing endpoints when planning routes or pricing by distance band.
• Build vs buy: for basic containment and distance-to-set queries, this reduces the need for a paid geospatial API or a dedicated PostGIS/Elasticsearch geo stack. We keep per-request vendor cost and data-residency questions out of the equation for the common case.
• Roadmap shaping: location-aware features (zones, territories, distance-based pricing, eligibility rules, boundary-based access control) can be scoped as small increments on existing data instead of a platform bet. Each capability becomes a candidate feature rather than an infrastructure prerequisite.
• Use cases to evaluate now: delivery/service-area eligibility, store-locator availability, territory assignment for sales or field ops, venue/event boundaries, regional access control, and "farthest from hub" reporting for ops dashboards.

When to Consider This Package

• You already store points and areas in the app and need containment or distance questions answered inside Laravel with Eloquent-friendly results.
• Your geometry needs are modest: 2D point-in-polygon and distance/farthest-point over a known set of points. This release is additive and backward-compatible — no migration work implied, so adoption can be opportunistic per feature.
• You want to avoid standing up PostGIS, a spatial index service, or a metered maps API for simple checks.
• Look elsewhere if: you need routing or drive-time, address geocoding, high-precision geodesic/3D/spheroidal math, very large polygon sets requiring spatial indexes, or regulatory-grade geofencing with audit trails.
• Validate before committing: how areas are represented (polygon vs multipolygon vs circle), coordinate system and units assumptions, behavior for points exactly on an edge, antimeridian/dateline cases, and query performance at your data volume. For a "farthest point" feature, confirm whether distance is planar or great-circle, since that changes results at scale.

How to Pitch It (Stakeholders)

For executives: v2.2.0 adds two capabilities we can productize — "is this point inside our area?" and "which point is farthest from this one?" Together they unlock service-area eligibility and coverage analysis without new vendor spend or a GIS program. It is an incremental, low-risk addition to an existing dependency, with no breaking changes signaled, so we can pilot one feature and measure before expanding.

For engineering: two well-defined primitives with narrow scope — point containment in a given area, and farthest-point selection from a set relative to a custom point. Both fit existing data models and avoid external service calls. The work is in edge cases, not integration: boundary points, complex or multiple polygons, coordinate-system and distance-metric assumptions, and performance at our row counts. Recommend a short spike covering those cases before we commit to a customer-facing guarantee.