Filament Map Picker Laravel Package

Product Decisions This Supports

Build vs. buy for a seemingly trivial field. Capturing a latitude/longitude pair looks like a 30-minute task and is not. A production-grade picker needs a map tile provider, click-to-place, drag-to-adjust, marker re-hydration from existing DB values, form state round-tripping through Livewire, validation (null, out-of-range, out-of-bounds), and mobile touch behaviour. This package collapses that into a Filament form component, which lets you decide "adopt" instead of "schedule a sprint."

Feature scoping for location-aware surfaces. It directly unlocks or de-risks a class of features that otherwise get deferred:

• Store / branch / depot locator and "nearest to me" search
• Property, listing, and real-estate records with an exact pin
• Delivery zones, service areas, and geo-fenced pricing tiers (via the Geoman polygon/rectangle/circle draw tools — this is the differentiating part versus a plain lat/lng pair of inputs)
• Field-service and asset tracking (equipment, plots, sites)
• Event venues, pickup points, and franchise territories
• Catchment/coverage visualisation for internal ops dashboards

Data model and roadmap implications. Because it captures drawn geometry, not just a point, it forces an early decision that echoes through the roadmap: do you persist a single point, a bounding box, or a full polygon/GeoJSON? That decision determines whether you later need PostGIS, a spatial index, and server-side point-in-polygon queries. Better to make it deliberately now than discover it when someone asks "which customers are inside this zone?"

Prioritisation signal. If your product has any physical-world dimension, a map picker is a low-effort, high-legibility feature — it demos well, it makes the admin panel feel finished, and it removes a recurring "we'll just type the coordinates in a text box" workaround that reliably produces bad data.

Risk containment. MIT-licensed, self-hosted, no vendor lock-in at the code level. The tile layer and the Geoman draw extension are the only external surfaces, and both are swappable, so this doesn't create a commercial dependency the way a Google Maps Platform integration would.

What v1.6.5 changes for the roadmap: nothing, and that's the point. This is a compatibility and assurance release, not a feature release: Laravel 10/11/12 support, plus new tests and QA. No new capabilities, no deprecations, no breaking changes flagged. The feature set the roadmap depends on — point, polygon, rectangle, circle capture — is unchanged. Treat the release as a confidence input, not a scope input.

When to Consider This Package

Adopt when:

• You are on Filament v3+ and already use it for admin/back-office. This is a hard prerequisite — the value proposition is the native form-component integration. Outside Filament, there is nothing here for you. Note that v1.6.5 documents the Laravel version matrix (10/11/12) but says nothing about the Filament matrix — that remains unconfirmed and is the gating check, not the Laravel one.
• You need point plus drawn area capture in an admin form, not just a coordinate pair. The Geoman draw tools are the reason to pick this over a simple map-click field.
• The consumer is internal operators or trusted admins, not public end users. Admin-panel ergonomics, not consumer-grade UX, is the design centre.
• Your team is small and the alternative is genuinely "build it ourselves." Realistic build cost: 1–3 days for a working point picker, 1–2 weeks for polygon drawing plus robust persistence, validation, and mobile handling.
• You can accept single-maintainer risk on a non-critical-path feature. Stars (7) and dependents (0) still say this is early and unproven. The v1.6.5 addition of tests and a three-version Laravel support window is a genuine step up in maturity, but it is one data point, not a track record. Treat it as a head start on your own implementation, not as infrastructure.

Look elsewhere or build when:

• You need authoritative geocoding, address search, or routing — this is a picker, not a geocoder. Pair it with a geocoding service or choose a fuller maps integration.
• You need server-side spatial operations at scale: point-in-polygon, intersection, area/perimeter computation, spatial indexing. That is PostGIS's job; this package only produces the input geometry.
• You must persist and query GeoJSON/WKT geometries with strong typing. Verify what the component actually emits and whether your schema, casts, and validation can absorb it before committing.
• You are on Filament v2, or plan a Filament major upgrade soon. Plugin breakage across Filament majors is common; budget for a fork or a rewrite at upgrade time. v1.6.5 does not change this calculus.
• You need vendor support, SLAs, or a security review trail. There is no commercial backing here, and the release notes explicitly describe the new QA as AI-assisted — useful, but not a substitute for human security review.
• Your use case demands consumer-facing polish — autocomplete, current-location, offline tiles, custom basemaps, accessibility. You will outgrow this quickly.
• You are subject to tile-provider terms of service constraints (usage caps, attribution, commercial licensing). The package doesn't solve that for you.

Practical due-diligence checklist before adoption: confirm the supported Filament version matrix (the release notes only cover Laravel); confirm the emitted data shape (lat/lng vs. GeoJSON vs. array); confirm what happens on edit/re-hydration of an existing geometry; verify the package identity and namespace — the v1.6.5 changelog resolves to vitormicillo/filament-map-picker, while earlier references used a different vendor prefix, so confirm the canonical repo before pinning; review the newly added tests to see what they actually cover (save/load, validation, geometry round-trip); check issue tracker and commit cadence; and pin the version. Fork it into your own namespace if the feature is on a revenue path.

How to Pitch It (Stakeholders)

For executives — one paragraph: We can add map-based location capture to the admin panel in days rather than weeks by adopting a small, MIT-licensed open-source component instead of building one. It gives operators a click-and-draw map to record an exact point, service area, or delivery zone, which unlocks locator, territory, and geo-fenced pricing features we've been deferring. There is no licence cost and no vendor lock-in. The latest release broadened framework compatibility and added automated tests, which improves confidence, though the project is still young with a single maintainer. We should treat it as a starting point we own rather than a dependency we rely on — engineering will vendor it and cover it with our own tests.

For engineering — the ask: Evaluate this as a Filament form component for geo-coordinate capture. It wraps Leaflet plus @geoman-io/leaflet-geoman draw tools (point, polygon, rectangle, circle) into a native field. v1.6.5 adds Laravel 10/11/12 support and a new test suite — review the tests, but note they were described as AI-assisted QA, so treat them as a floor rather than a guarantee. Before we commit: (1) confirm our Filament version is supported — the release notes only certify Laravel; (2) confirm the canonical repo/namespace, since the changelog and our notes disagree on the vendor prefix; (3) document the exact payload it emits and how it re-hydrates on edit; (4) decide our persistence target — plain lat/lng columns for the point case, or GeoJSON/PostGIS if we're shipping zones; (5) fork and pin it, and add integration tests around save/load and validation; (6) confirm the tile provider and attribution obligations. Estimate: roughly one day to spike, two to three days to productionise with tests, contingent on the persistence decision.

For design — the constraint: this is an operator-grade control inside the admin panel, not a consumer map experience. If the roadmap calls for customer-facing maps with search, geolocation, and curated basemaps, scope that separately — this package will not get us there.