Filament Map Picker Laravel Package

Product Decisions This Supports

• Feature delivery for location-aware admin workflows. filament-map-picker adds an interactive map field to Filament form schemas so an operator can drop a pin and persist latitude/longitude. This directly supports features like store/branch locators, delivery-zone setup, property and asset registration, event venues, field-service dispatch origins, and service-area definition.
• Build vs. buy (buy/skip-build) decisions. The realistic alternative is a custom Filament field plus a map JS library plus coordinate validation and state handling — typically several days of engineering plus ongoing upkeep. This package collapses that to a composer require and a form-schema entry, which materially shifts the cost calculus in favor of adoption for any team without in-house mapping expertise.
• Roadmap sequencing. Because the component is small and isolated, it is a low-risk "quick win" that can unlock a location-dependent epic (e.g., dispatch, geofencing, nearest-branch routing) without committing to a broader geo platform investment.
• Scoping the geo problem correctly. The package captures a point; it does not provide address autocomplete, reverse geocoding, routing, or polygon drawing. Using it forces the PM to explicitly decide whether "pick a location" is enough for v1 or whether a geocoding provider (Google Places, Mapbox, Nominatim) must be budgeted as a separate workstream.
• Risk and dependency decisions. Version 1.0.1 is a patch on a young 1.0 line, and the release notes carry no detail beyond a changelog diff link. That is a signal for the PM to treat the dependency as pinnable and replaceable — adopt behind a feature flag, lock the version, and avoid letting map rendering become a load-bearing part of the product surface without an abstraction around coordinate storage.

When to Consider This Package

Consider adoption when:

• The stack is Filament (v3-era) on PHP 8.1+ and the need is a single-point picker inside an admin/resource form.
• The product requirement is genuinely "mark a spot on a map and save coordinates" — no geocoding, no multi-point routes, no polygons.
• The team is small or lacks front-end mapping skills, and the alternative is a bespoke Leaflet/Google Maps integration with its own tile-provider, API-key, and lifecycle concerns.
• The feature is internal/back-office, where a slightly rough UX is tolerable and the blast radius of a bug is contained.
• You can pin the version and accept a young package's maintenance cadence.

Look elsewhere (or build) when:

• You need address search / autocomplete / reverse geocoding in the same field — that is a different (and paid-API-shaped) problem.
• You need polygons, circles, multi-stop routes, or drawing tools — evaluate a dedicated geo library or a custom field.
• You are on Filament v4 or a future major; a 1.0.x package's compatibility matrix is not a safe assumption, and the empty 1.0.1 notes give no compatibility signal.
• You have strict self-hosting/tile-provider or data-residency constraints (e.g., no third-party tile CDN), or a hard requirement for Google Maps specifically.
• Package health checks fail: no tests, stale issue tracker, no recent commits, unclear license, or no stated support window. Before committing, verify license terms, Filament version constraint, and whether the coordinate field validates/normalizes input (lat/lng range, nulls, precision).

How to Pitch It (Stakeholders)

To executives: This is a small, free, open-source Filament component that lets our admin users place a location on a map and have it saved automatically. It turns a location-aware feature — branch locator, delivery zones, asset tracking — from a multi-week engineering project into a few days of integration. There is no license cost and no vendor lock-in: it is an isolated form field, so if it disappoints we swap it out without touching our data model. The main caveat is maturity — it is a young 1.0-line package — so we recommend a scoped pilot behind a feature flag with a pinned version, not a company-wide dependency.

To engineering: It is a Filament form field that renders an interactive map and writes lat/lng back to the form state. Surface area is small: one schema component plus persisted coordinates. Integration is a composer require, a field in the resource form, and a migration for the coordinate columns (store as decimal(10,7)/decimal(10,7) or a spatial point depending on query needs). It deliberately does not do geocoding, routing, or polygonal areas — if the requirement grows past a single point, we will need a separate provider integration. Two asks before we ship: pin the exact version and wrap it so coordinate storage stays provider-agnostic; and confirm Filament/PHP version constraints against our app, since the 1.0.1 release notes are a changelog link only with no documented breaking changes or compatibility statements. Treat 1.0.1 as a routine patch — no new features or deprecations are indicated — and re-evaluate the dependency once a 1.1+ release ships with substantive notes.