Nova Google Polygon Laravel Package

Product Decisions This Supports

• Feature scoping: Enables polygon-drawing in Laravel Nova admin forms for use cases like service areas, delivery zones, territory assignment, property boundaries, geofencing, and site coverage maps. This is a narrow admin UX feature, not a geospatial platform.
• Data model decision: Forces an explicit choice on how geometry is stored — typically GeoJSON/coordinate arrays in a JSON column. PM should confirm downstream needs: display-only vs. spatial queries, point-in-polygon checks, exports, and map rendering.
• Build vs. buy/fork: The package is a small Nova field wrapper around Google Maps polygon drawing. If the team already uses Nova and Google Maps, it can save a few days of UI work. Because it is archived with 0 dependents and 5 stars, treat it as a starting point or internal fork, not a strategic dependency.
• Roadmap prioritization: Useful for validating demand for map-based admin workflows before investing in a custom field, spatial database (PostGIS), or dedicated geospatial service. If polygon editing is core to the product, plan a first-class solution rather than relying on this package.
• Use-case fit: Best for internal ops/admin panels where a small number of trusted users draw or adjust polygons. Poor fit for customer-facing map editing, high-volume geometry processing, or compliance-sensitive location workflows.

When to Consider This Package

Consider it only when:

• The product already uses Laravel Nova and needs a quick internal polygon-drawing field.
• The requirement is admin-side capture/edit of simple polygons, not complex GIS analysis.
• The team is willing to fork and maintain the package, since it is archived and has no dependent ecosystem.
• Google Maps JavaScript API is already approved, funded, and configured with API-key restrictions.
• Compatibility has been verified against the current Nova, Laravel, and PHP versions.
• The data can be stored simply (e.g., GeoJSON in JSON) and downstream consumers can handle that format.

Look elsewhere when:

• The package must be actively maintained, security-patched, or supported by a vendor.
• You need spatial queries, point-in-polygon validation, multi-polygon geometry, holes, or topology editing — evaluate PostGIS/GEOS or a dedicated mapping library.
• The product is customer-facing, requires accessibility guarantees, or needs map-provider flexibility (Mapbox, Leaflet, OpenStreetMap).
• Licensing, procurement, or long-term support requirements prohibit adopting an archived dependency.
• The team cannot assign an owner to fork, test, and maintain the field.

How to Pitch It (Stakeholders)

Executive summary: This is a small MIT-licensed Laravel Nova field that lets admins draw Google polygons in the admin panel. It can accelerate delivery of map-based admin workflows by a few days, but it is archived, has negligible adoption, and has no recent releases. Recommend using it only as a pilot or internal fork, not as a long-term platform dependency.

For engineering: Evaluate compatibility with the current Nova/Laravel/PHP stack, vendor or fork the code, add tests around GeoJSON serialization and null/empty states, and document ownership. Confirm Google Maps API billing and key restrictions. Budget roughly 1–3 days to fork, verify, and harden — more if spatial validation is needed.

For product: It supports quick validation of polygon-based admin features such as service areas and delivery zones. It does not provide geospatial querying, validation, or a customer-facing editing experience. If polygon editing becomes core, plan a follow-up investment in a maintained mapping solution or PostGIS-backed geometry model.