Form Spatial Laravel Package

Product Decisions This Supports

• Build vs. buy for spatial form inputs: The package supplies Symfony form types for entering/validating spatial data (geometry fields) — the kind of thing needed when an admin UI must accept a point, line, or polygon rather than a lat/lng pair. It answers "do we buy a form-field library or hand-roll the widget?" for legacy Symfony 2.x applications.
• Roadmap scoping for geospatial admin tooling: Where a backlog item is "let ops edit coverage areas / route geometries / property boundaries," this tells you a pre-built widget existed and is now unmaintained — so the realistic roadmap line is a custom form type, not a dependency.
• Ecosystem fit check (the primary decision): Despite being filed as a "Laravel/PHP package," this is a Symfony2 bundle (FormSpatialBundle). It has no Laravel service provider, no config/ publishing, no facade — it cannot be dropped into a Laravel app. For any Laravel-based product, the decision is effectively closed: build the equivalent as a custom Blade/Livewire or Inertia component.
• Vendor-risk triage: Archived, last release April 2018, GPL-2.0, 7 stars, 0 dependents. That combination means: no security patching, no PHP 8+ compatibility guarantees, no community to absorb bugs, and a copyleft license that needs legal review before it touches a proprietary codebase. Any decision to use it is really a decision to fork and own it.
• Use-case triage: The only defensible use case is maintaining an existing Symfony 2.8/3.x application with a live geo-form requirement and no budget to modernize — where the alternative is a multi-week rewrite rather than a one-line composer require.

When to Consider This Package

Consider it only when all of the following hold:

• The application is already on Symfony 2.8 or 3.x with an existing looptribe/spatial stack in composer.json, and you're keeping the lights on rather than building forward.
• You have an existing dependency on this bundle (legacy inherited codebase) and the question is "remove or keep," not "adopt."
• Legal has cleared GPL-2.0 for your distribution model, or the code stays internal.
• You have engineering capacity to fork and maintain it yourself — pinning to a vendored copy, patching PHP 8 deprecations, and owning the geometry validation logic.

Look elsewhere — decisively — when:

• The stack is Laravel. This is the common case, and it's a non-starter. Build a custom form component or evaluate maintained packages (e.g., a Leaflet/Mapbox front-end widget paired with a GeoJSON column cast such as matanyadaev/laravel-eloquent-spatial or clickbar/laravel-magellan for the persistence layer).
• The stack is Symfony 5/6/7. The bundle predates the Symfony Flex/form-type conventions you're using. Write a custom FormType — a geometry form type is typically a day or two of work and far cheaper than resurrecting an archived bundle.
• You need supported, patched dependencies. Archived + zero dependents + 2018 is the definition of unmaintained. Anything security-relevant in the geometry parsing path is yours to own.
• The requirement extends beyond form input — spatial queries, distance search, indexing. This package does none of that; you'd need PostGIS/MySQL spatial support plus a proper ORM spatial extension regardless, at which point the form widget is the smallest piece.
• The license is a blocker for a commercial or SaaS distribution.

How to Pitch It (Stakeholders)

One-line summary: A 2018-era, archived Symfony2 form bundle for spatial input fields. It is not a Laravel package and not a viable new dependency — treat it as reference material, not a component.

For executives: We evaluated it and recommend against adoption. The package is archived with no releases since 2018, no downstream dependents, and no maintainer, so any use transfers 100% of the support burden to us. Its GPL-2.0 license also creates legal friction for proprietary distribution. Cost of reproducing the functionality that matters — a map-based geometry input bound to our form layer — is on the order of a few engineering days, which is materially cheaper than the ongoing cost and risk of owning an abandoned dependency.

For engineering: The bundle predates modern Symfony form-type conventions and has no Laravel integration whatsoever. If we need spatial form input, the pragmatic path is a thin custom form type (and, on Laravel, a Livewire/Inertia component) backed by a maintained spatial persistence layer — PostGIS or MySQL spatial columns with a modern Eloquent spatial cast. Read the source for its geometry validation approach if useful; do not add it to composer.json.

Recommendation: No-go for adoption. Low direct cost, but negative expected value once maintenance, licensing, and framework-incompatibility risk are priced in.