Nova Geolocation Field Laravel Package

Product Decisions This Supports

• Feature scope: location capture in back-office tools. Enables a map-based lat/lng picker inside Laravel Nova admin screens — useful for store locators, service areas, delivery zones, venue/asset registries, property listings, or any entity that needs a physical point rather than a free-text address.
• Build vs. buy (or build vs. fork). A drop-in field is materially cheaper than commissioning a custom map picker with geocoding, validation, and coordinate storage. The decision this informs is whether a 1–2 day integration beats a 2–4 week build.
• Data quality roadmap. Lets you test whether structured coordinates (vs. typed addresses) reduce downstream cleanup, failed geocoding, and manual ops corrections — a measurable hypothesis you can validate before investing in a full geo data model.
• Prioritization input for geospatial investment. This package answers "can we store a point?" but not "can we query by radius, polygon, or route?" It cleanly separates the cheap, near-term need (capture) from the expensive one (spatial querying/PostGIS, routing, geofencing) so those stay distinct roadmap items.
• Admin UX standardisation. If multiple internal tools capture addresses inconsistently, adopting one field type sets a convention for coordinate precision, map provider, and required-field rules.
• Vendor/architecture decisions. Forces an explicit choice about map provider (Google Maps API keys, billing, ToS) and where coordinates live in the schema — decisions that are painful to reverse later.

When to Consider This Package

Adopt when:

• You are already running Laravel Nova and the package's supported Nova/PHP versions match your stack (verify this first — the repo shows zero stars and zero dependents, so treat version compatibility as unproven).
• The need is internal, low-volume admin data entry, not a public-facing map experience.
• You only need to store a point (lat/lng) and render it in the admin form — not to search, sort, cluster, or route by it.
• You can absorb the maintenance: the project has no community traction (0 stars, 0 dependents) and shows fork-like provenance. Assume no upstream support; budget for vendoring or owning the code.
• Google Maps API cost and key management are acceptable in your environment.

Look elsewhere when:

• You are not on Nova, or you are on a Nova version the field does not support.
• You need geospatial querying (radius search, bounding boxes, polygons, distance sorting) — a form field does not give you this; you need database-level spatial support.
• You need multi-point geometries, geofences, route optimisation, or map visualisations beyond a single marker.
• You require an actively maintained dependency with a security/upgrade path — the signals here (orphaned fork, no dependents) make that a hard no for customer-facing or regulated surfaces.
• Accessibility, i18n, or non-Google map providers are hard requirements.
• A simpler alternative already exists in your stack: two numeric lat/lng inputs plus a lightweight map preview gets most of the value with zero dependency risk.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost component that lets operations staff drop a pin on a map instead of typing an address into the admin panel. The business value is cleaner location data — fewer bad addresses, less manual correction, faster setup of new stores/assets/zones. It is not a geo-search or mapping platform; it captures a point and nothing more. The commercial case is a short integration against a multi-week custom build, and it is deliberately scoped as a reversible, internally-facing bet rather than an architecture commitment.

For engineering: It is a Nova field that renders a Google Maps picker and persists coordinates. Two caveats to plan around: (1) the package is effectively orphaned — no stars, no dependents, forked lineage — so we should pin the version, review the source, and be ready to vendor it; (2) version compatibility with our Nova/PHP baseline must be confirmed before we commit. Recommend a one-day spike: install, verify form behaviour on our Nova version, confirm API key handling and billing, and write down the exit criteria (schema we control, coordinates in plain columns) so removing it later is a migration, not a rewrite.

Ask: Approve a time-boxed spike plus a decision checkpoint — if the field doesn't fit our Nova version or requires more than a day of patching, we fall back to plain lat/lng inputs and revisit only when geospatial querying becomes a real roadmap item.