Filament Geometry Laravel Package

Product Decisions This Supports

• Filament v5 upgrade planning: Version 0.8.1 adds Filament 5.x compatibility, which unblocks teams planning a v4 → v5 migration. This is the difference between "blocked" and "ship it" for any admin panel that needs map/geometry input.
• Build vs. buy on geo-input: A lightweight, single-purpose field (draw points/lines/polygons on a Leaflet map, persist as GeoJSON/WKT) is a classic "don't build it" case. The alternative is custom Leaflet + Livewire + validation glue that you then own forever.
• Feature scoping for location-based products: Enables roadmap items such as service-area definition, delivery zones, site/asset plotting, property boundaries, territory assignment, and geofenced campaign targeting — without a GIS hire or a mapping microservice.
• Speed of validation: Because it's a form field, geo capture can be added to an existing Filament resource in an afternoon. That makes it cheap to prototype whether users actually want to draw shapes before committing to a broader geospatial data model (spatial indexes, PostGIS, tile serving).
• Vendor/risk posture: A one-line dependency with a narrow surface area is a low-cost bet; the 0.8.1 patch also signals the maintainer is actively tracking upstream Filament releases rather than letting the plugin rot after a major.

When to Consider This Package

Adopt when all of these hold:

• You are on Filament (v4, or v5 as of 0.8.1) and the requirement is capturing geometry in an admin form — not rendering a polished public map or running spatial queries.
• Your needs are covered by the common primitives: point, polyline, polygon, and the associated draw/edit controls.
• GeoJSON/WKT in a JSON or text column is an acceptable storage shape for your current stage.
• You accept pre-1.0 semantics: minor versions may still shift, so pin the version and re-read the changelog on each bump.

Look elsewhere (or build) when:

• You need server-side spatial operations at scale — radius/containment queries, intersection, tiling. You want PostGIS/MySQL spatial types plus a dedicated geometry library, with this field as the input UI only.
• Your UX bar requires drawing on a custom basemap, offline support, multi-layer editing, snapping, topology validation, or coordinate-system conversion. Evaluate a full GIS front-end (Mapbox GL, MapLibre, Leaflet plugins) instead.
• You are not on Filament, or are pinned to a Filament version this release doesn't support — check the constraint before assuming coverage.
• You need SLAs, commercial support, or a stable 1.x API contract; this is community-maintained and pre-1.0.

How to Pitch It (Stakeholders)

To executives: One small open-source plugin lets our admin users draw geographic areas — service zones, territories, site locations — directly in the tools we already use, instead of us building a mapping feature from scratch. It costs us a dependency rather than engineering weeks, and the newest release keeps it compatible with our planned Filament upgrade, so it reduces migration risk rather than adding to it.

To engineering: swisnl/filament-geometry is a Filament form field that wraps a Leaflet draw control and persists geometry as GeoJSON/WKT. 0.8.1 is a patch adding Filament 5.x support — no API or storage changes, so it's a drop-in for the upgrade path. Treat it strictly as an input widget: it does not give us spatial querying, so any radius/containment logic goes through our own spatial layer (PostGIS or equivalent). Pin the exact version, since the package is pre-1.0, and confirm the Filament constraint in composer.json matches our target branch before we merge the upgrade.