Nova Google Polygon Laravel Package

Product Decisions This Supports

• Geofencing and eligibility logic without a spatial database. The package pairs a Nova field for drawing polygons on Google Maps with an in-PHP Polygon::contain() test, so “is this address/GPS point inside this zone?” becomes a plain application-level check. That directly supports decisions like should we accept this delivery order, which sales territory owns this lead, or is this signup inside our service area.
• Build vs. buy for geo features. The alternative is stitching together a map-drawing field plus PostGIS/MySQL spatial queries or a third-party geo API. This collapses capture (draw/edit polygons in the admin) and evaluation (containment) into one Composer dependency — a defensible “buy” for teams with modest geo needs and no appetite to run spatial infrastructure.
• Roadmap sequencing. Delivery-zone validation, territory-based routing/assignment, franchise coverage maps, and coverage-gap reporting all become incremental features rather than new platform work. Because containment is a decision input, correctness is a product requirement, not a nice-to-have: the fixed vertex/meridian/equator bugs previously produced silently wrong answers (rejected valid addresses, mis-assigned leads), and wrong-but-quiet is materially worse for the business than a visible failure.
• Deployment/ops scope. Dropping the ext-bcmath requirement removes a hard dependency from container images, managed runtimes, and shared hosting — less ops surface for the same functionality, with no code changes on our side.
• Upgrade risk posture. Patch-level release, no API change. That makes it a low-ceremony “take it now” decision rather than something that needs a migration plan or roadmap slot.

When to Consider This Package

Adopt when:

• You are on Laravel Nova (9–11 on the 2.x line; 1.2.1 for the 1.x line) and want admins to draw/edit polygons in the Nova UI.
• Your geo needs are containment only — point-in-polygon against a manageable number of polygons at modest query volume.
• You want to avoid operating a spatial database or GIS vendor for what is essentially zone lookup.

Look elsewhere when:

• Scale. Point-in-polygon is O(vertices) per polygon per point in PHP. Thousands of polygons with high query volume belong in PostGIS/MySQL spatial indexes or a dedicated geo service; this package is not a spatial engine.
• Geometry richness. No evidence of multipolygons-with-holes, intersection/union, buffering, or distance/radius math. Adjacent needs will outgrow it.
• Geodesic accuracy. Ray casting on lat/lng is planar. Fine for city-scale zones; questionable for shapes spanning large areas or crossing the antimeridian — validate before committing to continent-scale or polar use cases.
• Not on Nova. The drawing UI is the core value, and it is tied to a Nova licence. Without Nova, evaluate a standalone geo library instead.
• Data hygiene is weak. Degenerate/empty polygons now return false instead of throwing. That is a good defensive default, but it converts bad geometry into silent false negatives — you need upstream validation and monitoring, or you will under-serve customers without an error to alert you.
• Boundary semantics matter and are undocumented in your domain. Edges follow a documented half-open convention (min-latitude/min-longitude edges inclusive). That is exactly what you want for non-overlapping territories — a boundary point counts once — but you must record the convention in your own specs and test it, because it is a product rule, not just an implementation detail.

How to Pitch It (Stakeholders)

For executives (one line): This package lets operations staff draw service areas on a map and lets the product reliably answer “is this customer inside?” — without adding a spatial database or a GIS vendor. This release is a correctness and simplification fix: boundary, meridian, and equator cases that previously returned wrong answers or crashed now match an exact reference across 8M+ comparisons, a required PHP extension was removed, and there is no API change — so it is a low-risk upgrade we should take promptly.

For engineering: Patch-level composer update, no code changes. Fixes Polygon::contain() ray casting for shared-longitude vertices and near-equator coordinates (the old scientific-notation/bccomp path), replaces throws on empty or sub-three-vertex polygons with false, documents the half-open edge convention, and drops ext-bcmath. Two follow-ups worth doing: (1) audit any workarounds added for the equator ValueError and delete them; (2) add boundary-point regression tests, since correct behaviour now differs from the old buggy behaviour for existing stored polygons.

Risk framing: The previous defect was silent wrong answers at boundaries, not loud failures — which is why the fix matters beyond a version bump. The new behaviour is deterministic and documented, so containment results become something we can put in front of customers and auditors.